七． Linux 2.4调度系统的一些问题

1. 进程时间片

2.4内核中进程缺省时间片是根据以下公式计算的：

/* 节选自[kernel/sched.c] */ #if HZ < 200 #define TICK_SCALE(x)                    ((x) >> 2) #elif HZ < 400 #define TICK_SCALE(x)                    ((x) >> 1) #elif HZ < 800 #define TICK_SCALE(x)                    (x) #elif HZ < 1600 #define TICK_SCALE(x)                    ((x) << 1) #else #define TICK_SCALE(x)                    ((x) << 2) #endif #define NICE_TO_TICKS(nice)    (TICK_SCALE(20-(nice))+1) …… schedule() { …… p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice); …… }

如上所述，时钟中断将不断对当前运行的非IDLE进程进行时间片剩余值减1的操作，直至所有就绪队列中的counter都减为0了，就在schedule()中对每个进程（包括休眠进程）利用上述公式执行时间片的更新。其中在[include/asm-i386/param.h]中定义了HZ为100，而counter通常初值为0，nice缺省为0（nice在-20到19之间选择），所以，i386下counter的缺省值为6，也就是大约60ms（时钟中断大约每10ms一次）。

同时，对于休眠的进程而言，其参与计算的counter非0，因此实际上它的counter是在累加，构成一个等比数列COUNTER=COUNTER/2+k，1<k<=11，其最大值趋近于2*k，也就是说，2.4系统中进程的时间片不会超过230ms。

因为就绪进程选取算法中counter的值占很大比重（见"就绪进程选择算法"），因此，这种对于休眠进程时间片叠加的做法体现了Linux倾向于优先执行休眠次数比较多，也就是IO密集（IO-bound）的进程。

Linux设计者最初是希望因此而提高交互式进程的响应速度，从而方便终端用户，但IO密集的进程并不一定就是交互式进程，例如数据库操作需要频繁地读写磁盘，从而经常处于休眠状态，动态优先级通常较高，但这种应用并不需要用户交互，所以它反而影响了真正的交互动作的响应。

时间片的长度对系统性能影响也很大。如果太短，进程切换就会过于频繁，开销很大；如果太长，系统响应就会太慢，Linux的策略是在系统响应不至于太慢的前提下让时间片尽可能地长。

2. 内核不可抢占

从上面的分析我们可以看到，schedule()是进行进程切换的唯一入口，而它的运行时机很特殊。一旦控制进入核心态，就没有任何办法可以打断它，除非自己放弃cpu。一个最典型的例子就是核心线程中如果出现死循环（只要循环中不调用schedule()），系统就会失去响应，此时各种中断（包括时钟中断）仍然在响应，但却不会发生调度，其他进程（包括核心进程）都没有机会运行。

下面给出的是中断返回的代码：

/* 节选自[arch/i386/entry.S] */ ENTRY(ret_from_intr)                     GET_CURRENT(%ebx)                        #将current指针存到ebx寄存器中备用 ret_from_exception:                     movl EFLAGS(%esp),%eax                   #取EFLAGS中的VM_MASK位判断是否处于VM86模式                     movb CS(%esp),%al                        #取CS低两位判断是否处于用户态                     testl $(VM_MASK | 3),%eax                                    jne ret_from_sys_call                              #如果处于VM86模式或者处于用户态，就从ret_from_sys_call入口返回，否则直接返回                     jmp restore_all

这是此时唯一可能调用schedule()的地方（通过ret_from_sys_call，见"调度器工作时机"），但普通的核心线程不属于任何一种要求的状态，它能响应中断，但不能导致调度。

这个特点的表现之一就是，高优先级的进程无法打断正在核内执行系统调用（或者中断服务）的低优先级进程，这对于实时系统来说是致命的，但却简化了核心代码。内核中很多地方都利用了这一特点，能够不做过多保护地访问共享数据，而不用担心其他进程的打扰。