3. 实时性能
Linux 2.4通过就绪进程选择算法的设计区分实时进程和非实时进程，只要有实时进程可运行，非实时进程就不会获得运行机会。Linux又将实时进程分为SCHED_RR和SCHED_FIFO两类。SCHED_RR时间片结束后会发生调度，并将自己置于就绪队列的末尾，从而给其他rt_priority相同（或更高）的实时进程运行机会（见"调度器工作流程"），而SCHED_FIFO不会因时间片结束而放弃CPU（见"调度器工作时机"），或者出现更高优先级的实时进程，或者主动放弃CPU，否则SCHED_FIFO将运行到进程结束。
尽管Linux 2.4中区分了实时进程和非实时进程的调度优先权，但也仅此而已。不支持核心抢占运行的操作系统很难实现真正的实时性，因为实时任务的响应时间无法预测。有两种办法使系统的实时性更好，一种是采用设置类似抢占调度点的做法，一种就是使内核真正具备可抢占性。
即使是内核可抢占的系统，也并不一定满足实时性要求，它仅仅解决了CPU资源的访问优先权问题，其他资源也同样需要"被抢占"，例如实时进程应该能够从握有某个共享资源的普通进程手中夺得它所需要的资源，它使用完后再还给普通进程。但实际上，很多系统都无法做到这一点，Linux的调度器更是不具备这种能力。
4. 多处理机系统中的局限性
Linux的调度器原本是针对单处理机系统设计的，在内核发展过程中，不断通过补丁来提高多处理机系统（主要是SMP系统）的执行效率。这种开发方式一直持续到2.4版本，因此在2.4内核中，SMP应用仍然有很多无法突破的障碍，例如全局共享的就绪队列。很多研究团体都在针对Linux调度器的多处理机扩展性作研究，参考文献中列举了其中两个[5][6]，但最权威的改进还是在2.6内核中。
对于超线程CPU，Linux调度器的支持有限，它可以区分同一物理CPU上的两个逻辑CPU，在两个逻辑CPU都空闲的时候，调度器可以优先考虑将进程调度到其中一个逻辑CPU上运行（见"调度器工作流程"）。从原理上说，超线程CPU是存在两个（或多个）执行现场的单CPU，只有两个使用CPU不同部件（比如定点部件和浮点部件）的线程在其上运行的时候才有正的加速，否则，由于执行部件冲突以及Cache miss，使用超线程技术甚至会带来一定程度上的性能损失。Linux 2.4的调度器并不能区分哪些进程是"类似"的，哪些进程会使用不同的执行部件，因此，实际上无法恰当使用超线程CPU。对于其他更复杂的多处理机系统，例如目前高端系统中占统治地位的NUMA结构机器，Linux在调度器上基本未作考虑。例如进程（线程）总优先在创建它的CPU上运行（见"其他核心应用的调度相关部分"之"进程创建"），并倾向于保持在该CPU上（见"就绪进程选择算法"），整个CPU选择过程没有做任何局部性优化。
八． 总结
调度系统的表现关系到整个系统的性能，Linux的应用目前主要集中在低端服务器系统和桌面系统，将来很可能向高端服务器市场和嵌入式系统发展，这就要求调度系统有大的改动。。
