-2

The scheduler is not a thread but it's a kernel function, so there's no way to actually "see" what the scheduler is doing (I assume). These particular kernel parts are kind of invisible from the user (I assume again).

(Side question: what other parts are not visible from the user and don't show up as threads/process?)

I just don't know how to imagine these kernel parts if I don't see them. I mean, how and where are these invisible parts executed? Who has told the CPU to execute the scheduler after context-switching? Who has "instructed" the CPU to do so, and how?

AdminBee
  • 22,803
Allexj
  • 265
  • If you're interested in this in general, and not just on the details of the Linux implementation, you might want to see if you can browse books on operating systems etc. Or if you can find any toy OS's around that would have reasonably understandable documentation. (that latter part probably being the problem though.) Not that I could think of any off-hand, but saying this might troll someone into providing links. ;) – ilkkachu Apr 19 '22 at 10:17
  • Nobody instructs a CPU. A CPU instructs itself. Computers are strange loops. Nothing tells the CPU to run a process, either. We think of "software telling CPUs to do things" but actually, it is the CPU which reads the software and decides to do what the software says. – user253751 Apr 19 '22 at 11:14
  • think of the kernel as create_first_process(); while(is_computer_on() && !is_computer_on_fire()) {process *p = find_a_process_to_run(); run_process_for_a_little_bit(p);} – user253751 Apr 19 '22 at 11:17

1 Answers1

1

Your question is rather broad, I’ll address the scheduler parts specifically.

Since the scheduler is a function, it runs whenever that function is called. The reason I link to Elixir is that it allows you to explore the call sites for a given function (check the references to __schedule). For example, whenever the kernel gets ready to return to user space (e.g. after servicing a system call), it checks whether a re-schedule has been requested and if so, calls the scheduler.

So basically, the scheduler runs whenever the kernel wants it to. Potentially, the scheduler can run whenever the kernel has control, and that happens quite often.

See different process in Linux in a single core PC how been managed? and the links there for more details.

Stephen Kitt
  • 434,908
  • and the kernel can control when it gets control, by e.g. setting up timers, so it's even more "when the kernel wants" :) – ilkkachu Apr 19 '22 at 10:13
  • It's done with interrupts. For example, a process (call it P1) asks to read a disk file, and blocks (cannot continue). The read system call starts the I/O (disks are slow), sets the "reschedule needed" flag, and the scheduler finds a runnable process (not P1) and runs it. In the fullness of time, P1's I/O completes, the disk interrupts, and P1 is marked "runnable". P1 is put on the queue from which the scheduler picks. The kernel also gets interrupted by the clock, so runaway (or even greedy) processes don't take over the world. – waltinator Apr 27 '22 at 16:24