锐客网

  1. 首页 > 睿知 > it技术 > >

linux执行命令卡顿 linux卡顿( 五 )

IT技术时间


说完了Windows为什么操作GUI会很流畅，该说点不好的了，
# Windows经常会死机，为什么呢？
这很大程度上也和上面描述的调度器有关 。
仔细看这个操作行为驱动的动态优先级调度器，很大的一个问题就是容易饿死低优先级的进程，特别是Pbase P_{base}P base 很低的进程 。
Windows的解决方案是采用一个后台进程(学名叫做平衡集管理线程)轮询的方式，将超过秒级都没有被调度的进程的优先级拉升到很高的位置参与抢占 。
这个机制有啥问题呢？问题在于Windows需要第三方线程来缓解饥饿 ， 而不是靠调度器自身，这便增加了调解失败的可能：
* 第三方线程本身的问题没有按照预期工作 。
* 饥饿进程过多 。
* 饥饿进程优先级提升后又被抢占 。
* …
除了死机问题之外，Windows系统对于服务器版本的调度器调整做的也不够优雅，Windows仅仅是调整了服务器版本的系统参数 ， 而几乎没有对调度的算法做任何修改 。对于服务器版本 ， Windows只是将时间片延长了而已，同时几乎不再动态计算时间片，而是选择始终使用相同的一个足够长的值，以减少进程切换提高吞吐率 。显然这种方式并不妥当，因为动态优先级根据事件的提升，还是会造成进程间不断抢占，从而影响吞吐 。
不过，毕竟Windows是一个Desktop系统，本身就不是为高吞吐而生的，这种针对服务器版本的策略调整便是无可厚非了 。正如Linux服务器虽然可以很完美应对高吞吐场景，其Desktop版本比如Ubuntu，Suse不也是心有余而力不足吗？虽然Linux内核也有动态优先级提升这一说 。
# 该简单总结一下了 。
在人机关联上，Windows更加靠近人这一端，适应了人的操作行为，为操作该机器的人提供了良好的短时延体验 ， Linux相反 ， 它靠近机器一端，让CPU可以尽可能开足马力跑task而不是频繁切换，从而为客户端提供最大的数据吞吐 。
Windows的设计甚是精妙，考虑到了人的行为的每一个细节(除了对于死机的耐受力)，除了动态优先级和具体时间精确关联之外，对于待机恢复时间deadline在7秒内也是很值得拍案 ， 这个7秒的阈值考虑到了人的短期记忆的极限，如果有人突然想到了一个点子，需要打开电脑将其记录下来，那么打开电脑的时间如果超过了7秒 ， 那么可能这个点子就溜走了，所以待机恢复时间必须限制在7秒以内，哇塞不哇塞 。
对于MacOS/iOS没有过多的研究，但是可以想见应该也如Windows这般了 。因为它们都处在人机关联的人的这一端 。随便看了下MacOS的开发手册，找到了下面的段落：
当我找和GUI和调度相关的东西时，就在上面这段的下面，有这个定义：
嗯，看来内核也是能看到所谓的前台窗口的 。
不管怎么说 ， Windows ， MacOS/iOS这些系统，共同的特点就是 大多数情况下，同时只有一个焦点窗口在前端接受输入输出 。毕竟把窗口缩小排满一屏幕的很少见 。然后呢？然后这就是一个典型的场景?。?
你看看Win10，不就可以设置为平板模式吗？
倾其机器和操作系统内核所有资源和机制照顾这少数的，几乎是唯一的前台焦点窗口的处理进程，这几乎就是单进程处理?。?然后处理好用户的窗口切换即可，比如Windows的Ctrl-Tab 。
Linux如若按照这个思路，单独再写一个调度器，替换掉CFS，而不是增加一个调度类，如此一来将系统中所有的进程统一按照 优先级和事件相关联 的方式对待，我想问题应该能优化不少 。
已经快凌晨了，说点别的但是相关的吧 。

推荐阅读


上一篇：go语言上手快吗的简单介绍

下一篇：如何提升新媒体阅读量，新媒体时代如何有效阅读