9

上下文切换是否发生在就绪队列只有一个进程且使用循环调度的系统中？

假设单独进程的当前 cpu 突发跨越循环算法的多个时间片。

我的推理如下

在典型情况下发生定时器中断时可能发生的步骤是

  1. 发生中断。切换到内核模式
  2. 操作系统将当前上下文保存到 PCB 中（保存当前进程的寄存器、进程状态和内存管理信息）
  3. 执行许多特定于体系结构的操作，包括刷新数据和指令缓存以及 TLB。
  4. 将当前进程放入就绪队列
  5. 选择要执行的新流程
  6. 从该进程的 PCB 加载上下文
  7. 切换到用户模式。开始执行新进程

我现在认为操作系统不妨先检查就绪队列并检查是否有其他进程。如果没有，则不需要上下文切换。因此，处理定时器中断将需要在用户模式和内核模式之间切换，检查就绪 Q，并切换回用户模式以恢复进程的执行。

这是怎么回事？或者是否进行了适当的上下文切换，涉及不必要地保存单独进程的当前状态并恢复相同？

如果后者确实发生，是否有特殊原因？

这种混淆是由于试卷中的一个问题涉及计算在这种情况下上下文切换所花费的时间。给出的答案意味着确实发生了上下文切换。

我希望研究过内核代码的人能够对此有所了解。因此这个关于stackoverflow的问题。

4

1 回答 1

8

以下来自 Linux Kernel 的代码将澄清您的疑问。在不同的时间，内核会调用调度器来选择一个新的进程来运行。但可能会发现调度程序除了当前正在运行的任务之外没有找到其他任务。在这种情况下，调度程序将不会进行“上下文切换”，而只是什么都不做而返回。

例如，我给你来自 Linux 内核的代码

   .........
   if (likely(prev != next)) {<-- if next and current are same, then no context switch
            sched_info_switch(prev, next);
            perf_event_task_sched_out(prev, next);

            rq->nr_switches++;
            rq->curr = next;
            ++*switch_count;

            context_switch(rq, prev, next); /* unlocks the rq */
            /*
             * The context switch have flipped the stack from under us
             * and restored the local variables which were saved when
             * this task called schedule() in the past. prev == current
             * is still correct, but it can be moved to another cpu/rq.
             */
            cpu = smp_processor_id();
            rq = cpu_rq(cpu);
    } else {
     ............
于 2012-01-25T08:47:07.180 回答