在课堂上，我们学习了调度中使用的不同算法，例如抢占。有人问切换上下文的开销是否是一个问题，教授说它总是可以忽略不计。这是真的？根据维基百科，当上下文切换发生时，“进程的状态包括进程可能正在使用的所有寄存器，......加上可能需要的任何其他操作系统特定数据”所以基本上所有内容都需要保存到内存中我不会认为是微不足道的吧？
是否有任何算法/实现会考虑上下文切换所需的时间？例如，一个 10 毫秒的任务正在运行，但一个需要 8 毫秒的新任务进入队列，调度程序会说“忘记它”，因为额外的上下文切换回 10 毫秒不值得吗？
不能忽略，但也不算多。当然，如果进程更改和线程更改发生，用户寄存器可能会更多的段/保护寄存器。线程堆栈已经在内存中，不需要保存。在 I/O 上准备好线程的情况下，实际的上下文更改可能会被驱动程序代码的运行淹没。
10/8毫秒...
进程中的大多数上下文切换都比这快得多！在进程中的线程的情况下，我们经常谈论低 uS，一旦新线程运行，如果需要完成一些缓存刷新，可能会有更多的开销。如果新运行的线程属于不同的进程，则会有更多的开销 - 更多的寄存器要保存，更有可能缓存等。还有更多的开销是上下文切换涉及停止另一个内核上的线程而不是运行调度程序/dispatcher 因为需要中断其他核心。
最坏的情况 - 以上所有加上立即页面错误，因为新线程没有运行很长时间，以至于它的代码/堆栈/任何内容都已被分页。幸运的是，几乎不会发生。
如果那个 8ms 线程是你的视频流应用程序中的高优先级渲染线程，你不希望它延迟，导致抖动，因为操作系统调度算法为了一些可能的额外开销而把你搞砸了:)