为什么在不同的地方有很多 schedule() 调用？
why there is many schedule() call in different place?
我正在追踪Linux 0.11
https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/
我看到在不同的地方有很多 schedule() 调用，而不仅仅是 do_timer() 中的调用。
这里有几个问题：
每次定时器超时都会调用do_timer()(@sched.c)？该计时器基于 x86 中断调用?
因为在 do_timer() 之外有很多 schedule() 调用，我可以说这是一种抢占吗？或者目的是什么？
任何阻止调用 schedule() 以产生控制权的操作。
- 部分任务状态发生变化，需要在schedule()中更新。
- 一些任务正在运行，但仍有大量工作需要 schedule() 来平衡。
Since there are many schedule() calls outside of do_timer(), can I say that is kind of preempting? or what's the purpose?
为了真实OS；大多数任务切换的发生是因为任务阻塞等待某些东西（用户输入，网络数据包，磁盘 IO，..）或者任务解除阻塞因为它正在等待的事情发生了（并且解除阻塞的任务具有更高的优先级并抢占当前 运行 低优先级任务).
整个 "task switch caused by timer IRQ" 事情主要只是一个回退，以防止恶意 CPU hogs（拒绝服务攻击）；对于正常情况下的普通软件，您可以禁用它（从定时器 IRQ 处理程序中删除 schedule()），没有人会注意到或关心。 注：有人会说也是针对"non-malicious"CPU绑定任务，但是CPU绑定任务比较少见，而且（忽略Linux 调度程序从来都不适合任务优先级）对于 CPU 绑定任务，最好依靠有效的任务优先级系统（例如，给 CPU 绑定任务一个低优先级，这样几乎所有东西都会抢占它们).
另请注意，关于 OS 理论的各种课程都是从 "so simple it never actually happens in practice" 概念开始的，它几乎总是一个纯粹的循环调度程序，任务从不阻塞（通常带有 "Hey, we can accurately predict the future and know exactly how long each task will run for" 废话)，作为第一步（以 "learn to walk before you run" 的方式），这基本上是好的，但如果后面没有更现实和更复杂的概念（更好的调度算法、任务优先级、多个同步调度算法/ "scheduler policies"、多 CPU、interactive/latency 敏感任务，..）因为它给 student/victim 留下的只是错误信息（例如不断重复出现的 "all tasks switches are caused by timer IRQ" 误解）。
do_timer() (@sched.c) will be called every time the timer timeout? This timer is based on an x86 interrupt call?
我猜定时器是原始 PIT 芯片的 IRQ（假设 Linux 版本 0.11 是 "absolute beginner developer with no intention of making it portable" 成千上万志愿者修复一半最差部分之前的历史纪念品）。 =15=]
另外不要忘记调度程序将时间用于两件不同的事情 - "current task has used too much CPU time" 几乎无关紧要的事情，以及弄清楚何时 blocked/sleeping 的任务（例如因为他们调用 sleep()) 应该unblock/wake了。 do_timer() 可能适用于其中任何一个，也可能适用于两者（我不看就不知道）。
我正在追踪Linux 0.11 https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/
我看到在不同的地方有很多 schedule() 调用，而不仅仅是 do_timer() 中的调用。
这里有几个问题：
-
每次定时器超时都会调用
do_timer()(@sched.c)？该计时器基于 x86 中断调用?
因为在 do_timer() 之外有很多 schedule() 调用，我可以说这是一种抢占吗？或者目的是什么？
任何阻止调用 schedule() 以产生控制权的操作。
- 部分任务状态发生变化，需要在schedule()中更新。
- 一些任务正在运行，但仍有大量工作需要 schedule() 来平衡。
Since there are many schedule() calls outside of do_timer(), can I say that is kind of preempting? or what's the purpose?
为了真实OS；大多数任务切换的发生是因为任务阻塞等待某些东西（用户输入，网络数据包，磁盘 IO，..）或者任务解除阻塞因为它正在等待的事情发生了（并且解除阻塞的任务具有更高的优先级并抢占当前 运行 低优先级任务).
整个 "task switch caused by timer IRQ" 事情主要只是一个回退，以防止恶意 CPU hogs（拒绝服务攻击）；对于正常情况下的普通软件，您可以禁用它（从定时器 IRQ 处理程序中删除 schedule()），没有人会注意到或关心。 注：有人会说也是针对"non-malicious"CPU绑定任务，但是CPU绑定任务比较少见，而且（忽略Linux 调度程序从来都不适合任务优先级）对于 CPU 绑定任务，最好依靠有效的任务优先级系统（例如，给 CPU 绑定任务一个低优先级，这样几乎所有东西都会抢占它们).
另请注意，关于 OS 理论的各种课程都是从 "so simple it never actually happens in practice" 概念开始的，它几乎总是一个纯粹的循环调度程序，任务从不阻塞（通常带有 "Hey, we can accurately predict the future and know exactly how long each task will run for" 废话)，作为第一步（以 "learn to walk before you run" 的方式），这基本上是好的，但如果后面没有更现实和更复杂的概念（更好的调度算法、任务优先级、多个同步调度算法/ "scheduler policies"、多 CPU、interactive/latency 敏感任务，..）因为它给 student/victim 留下的只是错误信息（例如不断重复出现的 "all tasks switches are caused by timer IRQ" 误解）。
do_timer() (@sched.c) will be called every time the timer timeout? This timer is based on an x86 interrupt call?
我猜定时器是原始 PIT 芯片的 IRQ（假设 Linux 版本 0.11 是 "absolute beginner developer with no intention of making it portable" 成千上万志愿者修复一半最差部分之前的历史纪念品）。 =15=]
另外不要忘记调度程序将时间用于两件不同的事情 - "current task has used too much CPU time" 几乎无关紧要的事情，以及弄清楚何时 blocked/sleeping 的任务（例如因为他们调用 sleep()) 应该unblock/wake了。 do_timer() 可能适用于其中任何一个，也可能适用于两者（我不看就不知道）。