对昨天的“膜拜牛人：200+行Kernel补丁显著改善Linux桌面性能”很感兴趣，于是去看了原帖，仔细看下去却发现似乎不是那么回事。所谓显著改善 Linux 桌面性能，基本只对新闻中的那个视频设定的状况有效：你要开一个终端用 64 个线程编译 Linux 内核，然后再开一个终端放高清视频。这看上去不是 Linux 桌面用户面对的一般情景。借用原文的话“补丁的用途是设计自动为每个TTY创建任务组，降低延迟改进桌面交互性能。”TTY 在 Linux 桌面大体可以理解为终端窗口。 PulseAudio 和 systemd 的作者 Lennart Poettering 指出了这种方法的致命缺陷： 这个特性只对内核作者有意义，与普通桌面用户完全无关。因为首先，普通用户本来就不怎么用终端；

其次，如果他们用终端的话也绝不会在一个终端里开一大堆线程，在其他几个里面开一点。只有在这样的情况下这个补丁才有点用处。 在我的机器上这个补丁就完全没用（我还是个内核作者呢），因为我一般在 emacs 里面编译程序，而 emacs 并没有连接到终端（因为是个 X11/gtk 的版本）（也就是从桌面直接打开的图形界面），所以他不会在自己的调度组里面。

所以，这个补丁仅仅对这样的人有效：成天从 xterm 里面用 make -j 编译内核，同时还想从终端（还得是另一个）里面启动一个播放器看电影。 只有在这样这个补丁才有用。对任何其他人而言，这东西完全无关紧要。如果你不用终端，这东西没用。如果你不（在终端里）开一堆线程，这东西没用。如果你不在终端里面启动 mplayer，这东西没用。 ...

至少这样想：想想如果我们在用户空间里面实现这个策略，我们就可以同时支持旧的内核而且也不许要把所有东西都升级到还没发布的新内核。 突然之间，在内核里面搞这个就不再显得那么完美了不是么？ 我是完全没有计划让大家都在自己的 bash 里面做这个。我所说的只是把这个机制绑定到TTY上纯是疯了。而且这是个策略，理所应当在用户空间里面做，而且我们几乎就做到了。

... 在随后的跟贴里，Lennart 总结道： 这里讨论的内核补丁对*普通用户**完全**没**关*。 这个补丁只对那些在一个终端里面开 mplayer，在另一个终端里面 make -j 的人才有关。 至翻译完成为止还没人对此提出质疑。 此外，Lennart 还提供了一个用户空间脚本，只用 10 行不到就实现了比 200 行的内核补丁还要低一些的延迟，这也得到了 Linus 的认同。

查看:Re: [RFC/RFT PATCH v3] sched: automated per tty task groups