3. smp系统初始化
init_task在完成关键数据结构初始化之后，在进行硬件的初始化之前，会调用smp_init()对SMP系统进行初始化。smp_init()调用smp_boot_cpus()，smp_boot_cpus()对每一个CPU都调用一次do_boot_cpu()，完成SMP其他CPU的初始化工作。
/* 节选自[arch/i386/kernel/smpboot.c] do_boot_cpu() */
if (fork_by_hand() < 0) /* do_fork(CLONE_VM|CLONE_PID)创建一个新进程，与init_task一样具有0号pid */
panic("failed fork for CPU %d", cpu);
idle = init_task.prev_task; /*在进程列表中，新进程总是位于init_task的左链prev上 */
if (!idle)
panic("No idle process for CPU %d", cpu);
idle->processor = cpu;
idle->cpus_runnable = 1 << cpu; /* 在指定CPU上运行 */
map_cpu_to_boot_apicid(cpu, apicid);
idle->thread.eip = (unsigned long) start_secondary; /* 被调度到后的启动地址 */
del_from_runqueue(idle); /* idle进程不通过就绪队列调度 */
unhash_process(idle);
init_tasks[cpu] = idle; /* 所有idle进程都可通过init_tasks[]数组访问 */
该进程被调度到时即执行start_secondary()，最终将调用cpu_idle()，成为IDLE进程。
七． 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，见"调度器工作时机"），但普通的核心线程不属于任何一种要求的状态，它能响应中断，但不能导致调度。
这个特点的表现之一就是，高优先级的进程无法打断正在核内执行系统调用（或者中断服务）的低优先级进程，这对于实时系统来说是致命的，但却简化了核心代码。内核中很多地方都利用了这一特点，能够不做过多保护地访问共享数据，而不用担心其他进程的打扰。
本文地址：http://com.8s8s.com/it/it36929.htm