3. Real-time performance
Linux 2.4 distinguishes real-time processes and non-real-time processes, as long as there is a real-time process, and non-real-time processes will not be run. Linux also divides the real-time process into two categories: SCHED_RR and SCHED_FIFO. The schedule will occur after the SCHED_RR time film, and places yourself at the end of the ready queue, thereby runs the same (or higher) real-time process for other RT_PRIORITY (see "Scheduler Workflow"), and SCHED_FIFO will not The film is over to discard the CPU (see "Scheduler Work Time"), or a higher priority real-time process, or actively discard the CPU, otherwise SCHED_FIFO will run until the end of the process.
Although Linux 2.4 distinguishes out the real-time processes and non-real-time process scheduling priorities, it is only. The operating system that does not support the core preemption is difficult to achieve real real-time because the response time of real-time tasks cannot be predicted. There are two ways to make the system's real-time real-time, one is to use the settings similar to seize the schedule points, one is to make the kernel truly grabbility.
Even if the kernel can seize, it does not necessarily satisfy the real-time requirements. It only solves the access priority issue of the CPU resource. Other resources also need "preemptive", such as the real-time process, you should be able to share a share The common process of resources won the resources it needs, and it will give a normal process after it is used. But in fact, many systems can't do this, Linux's scheduler does not have this ability.
4. Limitations in multiprocessor systems
Linux's scheduler is originally designed for single processor systems, and continuously through patches to improve the performance efficiency of multiprocessor systems (mainly SMP systems) during the internal nuclear development process. This development method has continued to version 2.4, so in the 2.4 kernel, SMP applications still have many obstacles that cannot break through, such as global sharing Ready queues. Many studies have studied the multi-processor extension of the Linux scheduler, and two [5] [6] are listed in the references, but the most authoritative improvement is still in the 2.6 core.
For the Hyper-throw CPU, the Linux scheduler supports limited, it can distinguish between two logical CPUs on the same physical CPU, when both logical CPUs are idle, the scheduler can prioritize the process to run on one of the logical CPUs. (See "Scheduler Workflow"). As in principle, the hyper-thread CPU is a single CPU with two (or more) executing the site, only two threads using the CPU different components (such as fixed-point components and floating-point components) are active. The acceleration, otherwise, due to the implementation component conflict and Cache Miss, using hyper-threading techniques even brings some degree of performance loss. Linux 2.4 scheduler does not distinguish which processes are "similar", which processes use different execution parts, so the ultra-thread CPU cannot be properly used. For other more complex multi-processor systems, such as NUMA structural machines that are dominated in high-end systems, Linux is basically not considered on the scheduler. For example, a process (thread) always prioritizes running on its CPU (see "Process creation" of "other core applications") and tends to keep on the CPU (see "Ready Process Select Algorithm"), The entire CPU selection process did not do any partial optimization.
Eight. to sum up
