#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

上一页  [1] [2] [3]  下一页