首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

深度探索Linux操作系统:系统构建和原理解析 - 王柏生

《深度探索linux操作系统:系统构建和原理解析》是探索linux操作系统原理的里程碑之作,在众多的同类书中独树一帜。它颠覆和摒弃了传统的从阅读linux内核源代码着手学习linux操作系统原理的方式,而是基于实践,以从零开始构建一个完整的linux操作系统的过程为依托,指引读者在实践中去探索操作系统的本质。这种方式的妙处在于,让读者先从宏观上全面认清一个完整的操作系统中都包含哪些组件,各个组件的作用,以及各个组件间的关系,从微观上深入理解系统各个组件的原理,帮助读者达到事半功倍的学习效果,这是作者潜心研究linux操作系统10几年的心得和经验,能避免后来者在学习中再走弯路。此外,本书还对编译链接技术(尤其是动态加载和链接技术)和图形系统进行了原理性的探讨,这部分内容非常珍贵。

02

编程高手为啥都喜欢耍脚本?

脚本编程几乎在每一个平台上都存在,这是因为利用脚本常常会简化、加快很多批量处理的工作,它能实现很多传统编程语言的功能,但是对编写者却不需要关心什么编译器、解释器之类的东西,各个平台一定带有这玩意儿,因为系统本身就使用了很多脚本来完成启动、初始化等功能。一般的脚本语言的执行只同具体的解释执行器有关,所以只要系统上有相应语言的解释程序就可以做到跨平台。 所有的脚本都有如下特性:语法、结构、学习和使用都很简单。不需要编译,一边解释一边执行。重开发快捷而不是效率。目前的脚本有好几十种,常见的也有十几种,遍布各个

05

[linux][bcc]使用runqslower发现调度延迟问题

前言 在高性能网络模型下,使用polling模式,依然遇到了长尾20ms+的情况,远高于平均的1ms左右。怀疑是调度的延迟导致的。那么如何量化是不是内核的调度导致的呢?以及如何发现是什么原因导致的呢? 分析 调度延迟 在前文《[Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进》中分析过Linux中如何计算一个task的run delay:即一个task希望运行,但是得不到运行的时间统计,即run delay,也就是调度延迟。 那么问题来了,如果通过atop监控到某一个进程的run delay是2%,能说明那20ms的长尾延迟是因为调度延迟导致的吗?答案是不能。我们看下面的两种情况: 1,例如说,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms。在这个模型下,统计出来的run delay是2%。 2,另外一种模型下,例如 Run 980ms, Delay 20ms, Run 980ms, Delay 20ms,这个模型下,就会遇到20ms+的长尾延迟。 所以atop可以统计出来宏观的run delay延迟占比,但是不能统计出来具体的调度延迟极端情况。 runqslower工具 在bcc中提供了runqslower工具,可以通过参数控制,打印出来哪些进程的调度延迟超过了特定的阈值,例如希望知道哪些进程的run delay超过10ms,可以使用这样的命令:

04
领券