我就知道有人会这么说，然而那样就成了一篇议论文了，而我只是想写一篇随笔。所以，不管事实是不是那样，反正我就是觉得Windows，MacOS，iOS都很流畅，而Linux，Android却很卡。当然了，这里说的是GUI，如果考量点换成是Web服务的吞吐和时延，那估计结论要反过来了，不过那是客户端程序感觉到的事，作为人，who cares！
我写这篇文章还有一个意思，那就是想牵引一个话题，如果我们想把Linux，Android(当然，Android内核也是Linux)优化到GUI不再卡顿，我们应该怎么做。
大概是去年，一个炎热的午后，吃过午饭我和同事们在公司附近晃悠，就讨论 “为什么苹果手机就不卡，安卓手机不管多贵都很卡。” 记得一位同事说，iOS在GUI方面做了很多的优化，而Android却没有。
这话说对了！不过更为重要的一点是， 不谈具体场景谈优化，都是瞎折腾！
Windows也好，iOS也好，都知道自己的应用场景，因此针对自己的应用场景做了优化之后，妥妥在自己拿手的场景下甩Linux在该场景下的表现几条街了。
下面开始正式的技术层面的分析之前，先声明几点：
1.本文并不是在说Linux系统总体上很卡顿，而只是说Linux系统桌面版的GUI程序相比Winddows很卡顿，如果真觉得本文是在喷Linux，那就当是喷Linux桌面的吧。
2.本文不准备讨论X window和Windows窗口子系统一个在用户态一个在内核之间的差异，这无关紧要。我的想法是，即便是你将X window扔进内核，现有的Linux内核处理GUI，该卡顿还是卡顿。
3.本文仅从调度算法的角度来评价为什么Windows/iOS不卡顿而Linux却卡顿，当然还有别的视角，但并不是本文主题。
4.Windows内核调度的线程而不是进程，但是本文统一采用进程这个术语，没有别的原因，只是因为进程的概念是和现代操作系统概念相始终的，而线程是后来的概念。
先看服务对象
# 仅此就将Windows，MacOS/iOS和Linux的使用场景区分开来：
* Windows/MacOS/iOS系统，主要是被人操作，用来提供写文档，游戏，做报表，画图，上网浏览，视频播放等服务。
* Linux系统，主要提供网络服务，用来支撑各种远程的客户端，为其提供数据处理和查询，数据生成，数据存储等服务。
事实证明，Linux在其专业的领域已经做的足够好，但是问题是，为什么它在GUI处理方面却总是一直很糟糕呢？这就要看具体场景的差异了。
对于网络服务而言，其场景的行为是 可预期的 ，我们可以将这些场景简单归结为：
* 公平快速处理网络并发请求。
* 公平快速处理并发磁盘IO。
* 高吞吐CPU密集型数据处理与计算。
Linux优秀的O(1) O(1)O(1)调度器以及后来的CFS调度器可以非常完美的cover上述三个场景，至于说为什么，不必多说，简单归纳如下：
* 无论是O(1) O(1)O(1)的基于优先级的时间片轮转还是CFS的基于权重的时间配额，均可以既满足优先级的差别服务需求又保证高吞吐率，这些都来自于调度器本身而不是依靠频繁的切换。
* 额外的简单启发式奖惩机制可以让网络IO以及磁盘IO的响应度更高，同时又不影响CPU密集型计算服务的高吞吐。
上面的第二点是一个额外的辅助，照顾IO过程快速获得响应，这是一个非常棒的辅助，但是注意，再棒的启发式算法也总是辅助性的，提高响应度就是个辅助性的锦上添花的功能，以高吞吐为目标才是根本。
IO过程对于一台Linux服务器而言是与外界交互的唯一渠道，通过该渠道可以将处理好的数据送出到网络或者磁盘，同时从网络或者磁盘获取新的数据，换句话说， IO过程类似一道门。 但也仅仅是一道门。
照顾IO过程获得高响应度这件事是为了让门开得更大，通行效率更高！
熟悉Linux内核调度器变迁的都应该知道O(1) O(1)O(1)到CFS过渡的这段历史，即2.6.0内核开始一直到2.6.22为止的这些版本，采用Linux内核划时代的O(1) O(1)O(1)调度器，随后由于两个原因：
1、O(1) O(1)O(1)调度器动态范围太大或者太小。
2、IO补偿机制不到位，时间片分配不公平。
为了解决这些问题，Linux内核切换到了CFS调度器。
切换到了CFS调度器，事实上，人们更多指望的是CFS能够让进程时间片分配更加公平，多个进程运行更加平滑，如此一来，上GUI界面的话，岂不是就不卡顿了。
然而还是卡顿，本质原因是，场景根本就不对路子。
在Linux服务器的场景中，优先级和时间片是正相关的，无论是O(1) O(1)O(1)调度器的静态线性映射的时间片，还是CFS的动态时间配额，都是优先级越高的进程其每次运行的时间也就越久，但是实际上，这两者并不是一回事。
在更复杂的场景中，正确的做法应该是参考 时间管理的四象限法则 来设计进程调度器。其中：
* 优先级表示紧急性。
* 时间片表示重要性。
于是，如果不是因为Linux服务器场景过于单一简单，CPU的时间管理要复杂得多，比如调度器应该按照四象限法则设计成下面的样子：
1、处理重要且紧急事件的进程，需要赋予高优先级分配长时间片去抢占当前进程。
2、处理重要但是不紧急事件的进程，保持固有优先级分配长时间片就绪等待。
3、处理不重要但紧急事件的进程，提升优先级但不分配长时间片，处理完毕立即返回固有优先级。
4、既不重要也不紧急的后台进程，低优先级短时间片，系统闲了再调度。
后面我们会看到，Windows的调度器就是这般设计的。
我们先总体看看GUI系统的场景。
它的服务对象是人，和Linux的服务场景的行为可预期相反，人的操作是 不可预期 的！
Windows，MacOS/iOS这种Desktop系统的GUI进程，很多时候都是在等待人的进一步操作而睡眠，要么在等鼠标，要么在等键盘，要么在等声卡，显卡的输出，或者就是在将用户输入的信息往磁盘里写而等待IO完成，Desktop系统更多关注的是要对以上这些事件提供高效率的响应服务，而不是系统的数据吞吐。
Desktop在乎的是时延，而不是总吞吐，同时，这个时延还是区分对待的，有些时延的可容忍区间很大，比如网卡(网卡IO之所以优先级提升并不是很多，是因为首先网卡是有队列缓存的，而大多数的报文都是burst而来的，队列缓存可以平滑掉首包延迟，其次，由于光速极限，相比于网络延迟，主机调度延迟真的可以忽略不计。)，有些却很小，比如键盘鼠标。所以说，Windows之类的Desktop系统 必须能够区分一个进程当前的紧急性和重要性。
# Linux内核能做到这种区分吗？
Linux可以通过计算一个进程的平均睡眠时间判定它是不是一个交互式IO进程，从而决定要不是给它一定的优先级提升，但是也仅能做到这个地步，因为Linux内核无法得到更进一步的信息。
Linux内核不知道一个进程到底是不是IO进程还是说仅仅在一个时间段内有IO行为的CPU密集型进程，Linux内核也不知道一个进程被唤醒是因为键盘的数据到了，还是无关紧要的信号到了，所以这一切，Linux内核只能 启发式预测。
Linux内核仅仅跟踪一个睡眠时间而且还是平均的睡眠时间，是区别不出进程当前的紧急性和重要性的。没有外界的信息输入，仅靠启发预测，当前的AI算法貌似还没有到这个境界吧。换句话说，启发算法是不准确的。你看看Linux内核O(1) O(1)O(1)调度器的sleep_avg是如何计算并如何参与动态优先级调整的，就会明白我上面说的意思。
既然Windows系统的GUI操作比Linux流畅，那么想必Windows肯定是做到了进程当前的紧急性和重要性的区分咯？那是当然。它是如何做到的呢？
虽然Windows的调度器也是基于优先级的，也是抢占式的，也是同优先级轮转的，这看起来和Linux并没有什么区别，甚至从4.3BSD开始，几乎所有的操作系统的调度器基本都是按这个思路设计出来的，仅仅从 如何选出下一个投入运行的进程 这个算法上看，几乎所有的操作系统调度器都是一样的。Windows与众不同的原因在于 其对优先级的不同处理方式。
自4.3BSD以来，所有的基于优先级的抢占式调度器的优先级计算都包括两部分因子，即固有优先级和动态优先级：
一直以来，
只是起到了 微调 的作用，而
才更具有参考意义，其比重更大。
Windows与众不同，其弱化了进程(其实应该是线程，但是我就统一写成进程吧，为了照顾不懂Windows内核原理的读者)的初始基优先级
，而强化了动态优先级
，更重要的是，动态优先级的值并非来自预测，而是来自于 事件 ，事件本身的紧急性反馈到了动态优先级的值，而事件本身的重要性则反馈到了时间片：
可以看出，Windows对于不同的事件定义了不同的优先级提升的具体数值， 将动态优先级的值和具体的事件做了精确的关联。
这些数值的定义上，甚至精细而贴心，详细的数值参见ntddk.h：
//
// Priority increment definitions. The comment for each definition gives
// the names of the system services that use the definition when satisfying
// a wait.
//
//
// Priority increment used when satisfying a wait on an executive event
// (NtPulseEvent and NtSetEvent)
//
#define EVENT_INCREMENT 1
//
// Priority increment when no I/O has been done. This is used by device
// and file system drivers when completing an IRP (IoCompleteRequest).
//
#define IO_NO_INCREMENT 0
//
// Priority increment for completing CD-ROM I/O. This is used by CD-ROM device
// and file system drivers when completing an IRP (IoCompleteRequest)
//
#define IO_CD_ROM_INCREMENT 1
//
// Priority increment for completing disk I/O. This is used by disk device
// and file system drivers when completing an IRP (IoCompleteRequest)
//
#define IO_DISK_INCREMENT 1
//
// Priority increment for completing keyboard I/O. This is used by keyboard
// device drivers when completing an IRP (IoCompleteRequest)
//
#define IO_KEYBOARD_INCREMENT 6
//
// Priority increment for completing mailslot I/O. This is used by the mail-
// slot file system driver when completing an IRP (IoCompleteRequest).
//
#define IO_MAILSLOT_INCREMENT 2
//
// Priority increment for completing mouse I/O. This is used by mouse device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_MOUSE_INCREMENT 6
//
// Priority increment for completing named pipe I/O. This is used by the
// named pipe file system driver when completing an IRP (IoCompleteRequest).
//
#define IO_NAMED_PIPE_INCREMENT 2
//
// Priority increment for completing network I/O. This is used by network
// device and network file system drivers when completing an IRP
// (IoCompleteRequest).
//
// 网卡IO之所以优先级提升并不是很多，是因为首先网卡是有队列缓存的，而大多数的报文都是burst而来的，队列缓存可以平滑掉首包延迟，其次，由于光速极限，相比于网络延迟，主机调度延迟真的可以忽略不计。
#define IO_NETWORK_INCREMENT 2
//
// Priority increment for completing parallel I/O. This is used by parallel
// device drivers when completing an IRP (IoCompleteRequest)
//
#define IO_PARALLEL_INCREMENT 1
//
// Priority increment for completing serial I/O. This is used by serial device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_SERIAL_INCREMENT 2
//
// Priority increment for completing sound I/O. This is used by sound device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_SOUND_INCREMENT 8
//
// Priority increment for completing video I/O. This is used by video device
// drivers when completing an IRP (IoCompleteRequest)
//
#define IO_VIDEO_INCREMENT 1
//
// Priority increment used when satisfying a wait on an executive semaphore
// (NtReleaseSemaphore)
//
#define SEMAPHORE_INCREMENT 1
---------------------
仔细看，你会注意到对于声卡而言，其IO完成时，优先级提升会很大，而磁盘，显卡这种却并不是很多，这充分体现了设计者的贴心。这充分考虑到了人耳的灵敏度和人眼的分辨率之间的对比，声音是作为流顺序输出的，耳朵很容易分辨出声音的卡顿，而对于图像而言，完全可以慢慢双缓冲刷层，人眼相比之下没有那么高的分辨率识别到，因此声卡事件必须优先处理。
同时，对于磁盘，网卡之类的，人就更是感觉不到了。除了声卡之外，键盘鼠标操作的IO完成对于优先级提升的数值也很可观，因为键盘鼠标如果卡顿，人的输入会明显感觉到延迟，鼠标则显拖沓，这都是很容易识别的卡顿事件，所以Windows给予了进程更高的动态优先级来尽快处理这些事件。
对于窗口子系统而言，当一个窗口获得焦点时，对应的处理进程的优先级也会得到提升，这会给人一种 你操作的界面总是很流畅 的感觉，毕竟你操作的界面就是前台窗口，至于说此时后台窗口的处理进程，即便是僵死了你也不会有感觉，因为你并不操作它们呀，当你操作它们时，对应的处理进程的优先级就会提升。
所有的优先级提升都伴随着时间片的重新计算，但是和Linux不同的是，Windows并没有直接将进程优先级和时间片按照正相关关联起来，时间片是独立计算的，大多数时候，Windows对于所有的进程，不管优先级是多少，均采用同一个时间片。
如此看来，Windows虽然也是优先级调度的系统，但是其优先级却是 操作行为驱动的 ，这便是其与众不同之处。
Linux内核调度系统会精细区分磁盘事件的wakeup和键盘鼠标声卡事件的wakeup吗？不会。
说完了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，而不是增加一个调度类，如此一来将系统中所有的进程统一按照 优先级和事件相关联 的方式对待，我想问题应该能优化不少。
已经快凌晨了，说点别的但是相关的吧。
Linux内核O(1) O(1)O(1)调度器的历史其实很短暂，2.6初始到2.6.22，但是非常经典的Linux内核方面的书，都是在描述这期间的Linux内核版本，这在当时就给了人们一个假象，O(1) O(1)O(1)调度器是无敌的，是划时代的，于是，当有了新的CFS调度器的时候，人们哇塞一声，O(1) O(1)O(1)只是银河系级别的，而CFS是宇宙级别的。
但其实，O(1) O(1)O(1)的意义只是优化了 如何快速找到下一个要运行的进程 ，虽然它也涉及了动态优先级的计算，但是这并不是它的重点。说实话，你若看看Windows的调度器，4.4BSD，SystemV4的调度器，基本上都是位图加优先级队列的形式，思路几乎是同一个，这么说来都是O(1) O(1)O(1)咯，而且人家这些调度器早在Linux还是O(n) O(n)O(n)调度器的时候就已经存在好几年了，却无人问津。
Windows内核的调度算法不为人知的原因除了其闭源之外，还有一个原因就是Windows内核方面的技术总体上推广的人太少，国内除了潘爱民一直在致力于这方面的推广之外，在没有别人了。估计是因为大家觉得Windows内核方面，Debug之外的东西，学了也没啥用吧。
你说Linux开源没错，BSD不也开源吗？怎么就没有人注意BSD的调度器实现呢？哈哈，开不开源无所谓，关键得能造势搞事情，而且获取方便，让大家用起来你的东西才真真的啊。Linux2.4版本说实话及其垃圾，但关键是很多人用起来了，这就是全部了。Solaris虽然设计完美优雅，可是有壁垒，没人用，最终也还是凉凉。同样的事情参考以太网。
通篇都在比较Windows和Linux的调度器如何影响人们的操作体验。最后说说iOS和Android吧，题外话，不涉及技术。
Android就是卡，不接受反驳。
再贵的Android机器也卡，三星的，华为的照卡不误，只是相比别的稍微好一点点而已。这意味着它们成不了街机。因为手机是买来用的，不是买来debug的，除了程序员没人在乎Android机慢的原因，即便是程序员也很少有折腾明白的，只是因为这份职业让他不用Android就不正确。不过现在互联网公司的程序员用iPhone的也多了，因为好用啊。再者说了，互联网公司程序员大概率以做业务逻辑为主，底层技术欠缺，无力debug，当然是什么好用用什么，iPhone贵，但是互联网程序员收入高啊。
最终，Android机的唯一优势就是价格，你让Android卖的和iPhone一样贵试试，分分钟被绞杀。要说还有唯一点五的，就是品牌，XX也不是吃素的，就算XX做的再烂，就凭它这牌子，也不缺市场，比如我就是XX用户，我并不是觉得XX的Android比小米的Android好，而是我喜欢XX这个公司，这个品牌，仅此而已
df -h
iostat -x 1(一秒刷新一次) ，执行iotop命令查看具体进程IO占用
free -g
（total used free）
htop
1. 检查网络链接：确保Linux主机处于可用的网络中，并检查和确认IP地址，子网掩码和网关都是正确的。2. 检查DNS设置：查看/etc/resolv.conf文件，确保其中包括合适的DNS服务器信息。 DNS服务器可以定位特定的网站或主机的IP地址，如果DNS服务器不可用或无法正确作出响应，则该Linux主机将无法正常使用网络。
3. 调整TCP接收缓冲区大小：如果Linux主机处于一个快速网络中，而下行速度很慢，则可能需要调整TCP接收缓冲区大小。 运行```sysctl -w net.ipv4.tcp_rmem=4096 87380 8388608```命令来调整TCP接收缓冲区的大小，并使设置永久保存在系统上，需要将其添加到/etc/sysctl.conf文件中。
4. 检查防火墙：防火墙可能会拦截Linux服务器的流量，从而限制其上行和下行速度。 可以使用iptables或firewalld来查看和配置防火墙规则，并确保其中没有任何设置可能会限制Linux服务器的速度。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）