Linux 的一个问题一直是其系统调用的实现。正如 Andy Lutomirski 最近指出的那样，它非常混乱。他说，甚至要确定哪些架构实现了哪些系统调用都非常困难，确定调用的名称和编号之间的映射，以及调用参数寄存器和系统调用参数之间的映射也很困难。

一些用户程序，如 strace 和 glibc，需要知道这类信息，但它们收集这些信息的方式——尽管做得很好——也非常混乱。

Andy 提议仔细研究内核代码，编写一个文本文件，作为系统调用的“主列表”，给出调用名称、相应的调用编号、支持的架构和其他信息。 除此之外，这将允许 glibc 等工具消除其丑陋的实现，并使用一个简单的库从内核中获取这些信息。

H. Peter Anvin 喜欢这个想法，但表示要做好这项工作需要付出很多努力。他提到，长期以来，他一直在倡导类似的想法，可以追溯到他在 klibc 上的工作。

其他许多人也喜欢 Andy 的想法——特别是任何参与用户代码的人，他们目前不得不零散地推断系统调用的组织方式。David Howells 评论说，如果 strace 也能依赖 Andy 的主列表，那就太好了。而且，Michael Kerrisk 说，manpages 项目 也将有兴趣跟踪主列表的进展。

总有一些特殊情况可以从稍微调整进程调度器中获益，超出常规。最近，来自 Oracle 的 Khalid Aziz 提交了一些代码，允许用户进程声明额外的时钟片。通常，内核本身控制这种资源分配，否则系统将依赖于用户应用程序的友好性或良好编码。

但是，Khalid 的数据库人员注意到，大量线程争用同一个互斥锁时会出现问题。如果其中一个线程拥有互斥锁并且几乎准备好放弃它，调度器可能会运行整个其他进程队列，但这些进程都无法实际运行，因为它们都在等待同一个互斥锁。就像眼中钉一样，持有互斥锁的进程已经准备好放弃它，但却无法放弃，因为它已被抢占。Khalid 说，更好的做法是允许持有互斥锁的进程延迟抢占，足够长的时间来放弃该互斥锁。然后所有其他进程都可以轮流执行实际工作，而不是将宝贵的时钟片浪费在旋转等待不可用的锁上。

Khalid 说他的代码显示，相对于之前的情况，速度提高了 3-5%。但是，仍然有相当多的不情愿接受他的代码进入内核。

特别是，H. Peter Anvin 指出，Khalid 的代码允许用户空间将内核的自然抢占式多任务处理转换为协作式多任务处理模型，在该模型中，所有进程都必须就谁将获得时钟片以及何时获得时钟片达成一致——并且某些进程可能会积极地以牺牲其他进程为代价来声明时钟片。

Davidlohr Bueso 指出，自愿抢占模型可能更适合内核现有的实现，允许进程自愿将时钟片让给另一个进程。那里没有来自恶意进程的危险。

对于 Khalid 的设计，有各种替代方案的建议，但 Khalid 总是指出他的方法是最快的。但是，Thomas Gleixner 说：“这是一个可怕的想法。你正在创建的是一种基于水晶球的时间绑定优先级上限形式，具有我见过的最糟糕的用户空间接口。”

显然，这才是真正的问题。赋予用户代码抢占正常调度过程的能力意味着内核或其他用户空间进程都无法预测系统的行为，甚至无法正确调试问题。

Thomas 在某一点上说：“你试图做的是本质上创建一个 ABI，我们必须永远支持和维护它。这绝对值得提出一些严肃的问题。” 他补充说，“如果我们允许你特殊处理你的数据库工作负载，那么我们就没有理由不为实时工作负载做同样的事情，在实时工作负载中，SCHED_FAIR 家务线程可能会短暂地持有锁来访问 SCHED_FIFO 实时计算线程中的一些重要数据。当然，RT 人员也希望尽可能避免锁争用，只是原因不同。”

Eric W. Biederman 也反对 Khalid 的代码，他说：“你允许任何任务延长其时钟片。这意味着我会得到这样的问题：为什么 really_important_job 只有在与 sched_preempt_using_job 在同一台机器上运行时才会错过其延迟保证？” 他说，“你的更改似乎具有极难调试的非局部效应。”

似乎有很多人对实现像 Khalid 提出的那样的功能感兴趣，但似乎也存在安全问题、可调试性问题和可维护性问题，使得整件事非常不确定。但是，Khalid 仍然有可能解决这些问题，并提出一个补丁，在不造成混乱的情况下，实现数据库人员想要的功能。