why there is many schedule() call in different place?

Question

I am tracing Linux 0.11 https://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/

I see there are many schedule() call in different place, not just the one inside do_timer().

Few questions here:

1. do_timer() (@sched.c) will be called every time the timer timeout? This timer is based on an x86 interrupt call?

2. Since there are many schedule() calls outside of do_timer(), can I say that is kind of preempting? or what's the purpose?

Answer 1

Since there are many schedule() calls outside of do_timer(), can I say that is kind of preempting? or what's the purpose?

For a real OS; most task switches occur because a task blocks waiting for something (user input, network packet, disk IO, ..) or a task unblocks because something it was waiting for happened (and the unblocked task has higher priority and preempts the currently running lower priority task).

The whole "task switch caused by timer IRQ" thing is mostly just a fallback to guard against malicious CPU hogs (denial of service attacks); and for normal software under normal conditions you could disable it (delete the schedule() from the timer IRQ handler) and nobody would notice or care. Note: Some people will say it's also for "non-malicious" CPU bound tasks, but CPU bound tasks are relatively rare, and (ignoring the fact that the Linux scheduler has never been good for task priorities) for CPU bound tasks it's better to rely on an effective system of task priorities (e.g. give the CPU bound tasks a low priority so that almost everything will preempt them).

Also note that various courses on OS theory start with "so simple it never actually happens in practice" concepts, which is almost always a pure round-robin scheduler with tasks that never block (often with "Hey, we can accurately predict the future and know exactly how long each task will run for" nonsense), which is mostly fine as a first step (in a "learn to walk before you run" way) but sucks big salty dog balls if it's not followed by more realistic and more complex concepts (better scheduling algorithms, task priorities, multiple simultaneous scheduling algorithms/"scheduler policies", multi-CPU, interactive/latency sensitive tasks, ..) because it leaves the student/victim with little more than misinformation (e.g. the ever re-occurring "all tasks switches are caused by timer IRQ" misconception).

do_timer() (@sched.c) will be called every time the timer timeout? This timer is based on an x86 interrupt call?

I'm guessing that the timer was the raw PIT chip's IRQ (given that Linux version 0.11 was "absolute beginner developer with no intention of making it portable" historical memorabilia from before thousands of volunteers fixed half of the worst parts).

Also don't forget that the scheduler uses time for two different things - the "current task has used too much CPU time" thing that almost never matters, and figuring out when tasks that are blocked/sleeping (e.g. because they called sleep()) should unblock/wake up. The do_timer() might be for either of these things and might be for both (I don't know without looking at it).

Answer 2

1. Some tasks' state has changed, it needs to be updated in schedule().
2. Some tasks' are working and still a lot of work, schedule() for balance.

Answer 3

Any operation that blocks calls schedule() to yield control.