When you call a system call such as fork in process X, the kernel is said to be executing in process context. So, fork can be said to be running in process X, right?
But if schedule() is called (and it isn't a sys call) in the same process, would you say that it is running as part of X? Or does it runs in the swapper process? Or does it sound absurd, taking into account the monolithic nature of the kernel?
schedule() is always running in process context. The special part about it is that it can change which process context is current - but it does always have a process context. Prior to the call to context_switch() it runs in the context of the process to be swapped out, and after it runs in the process swapped in.
The Linux kernel does not have a dedicated "swapper" task (there is an idle task, which is always runnable in case nothing else is eligible to run).
It really depends upon where the schedule() call is made from; schedule() can be called both from process context or from a work queue. The work queues are kernel-scheduled threads:
# ps auxw | grep worker
root 1378 0.0 0.0 0 0 ? S 20:45 0:00 [kworker/1:0]
root 1382 0.0 0.0 0 0 ? S 20:45 0:00 [kworker/2:0]
root 1384 0.0 0.0 0 0 ? S 20:45 0:00 [kworker/3:1]
...
The [..] signifies that the processes do not execute in userspace.
The worker_thread() function calls schedule() after handling a work item but before starting all over again.
schedule() can also be called on behalf of a process, either by a driver or by signal handling code, or filesystem internals, or myriad other options.
The scheduler take care of all processes, so does not run inside one process.
Of course, when e.g. a process is scheduled out because of a clock interrupt, some process was running (and later, another one is scheduled).
You cannot view all the kernel as running for processes (only system calls are).
Q: So, fork can be said to be running in process X, right?
A: Yes, absolutely. The system call by which a process REQUESTS to "fork" occurs in user space. The act of making the system call TRANSITIONS from user space to kernel space. The IMPLEMENTATION of the system call may involve many separate steps. Some may occur in user space; other steps occur in kernel space.
Q: ...taking into account the monolithic nature of the kernel ?
A: The issue of "user space" vs "kernel space" has absolutely NOTHING to do with whether the kernel happens to be "monolithic", a "microkernel" or something else entirely.
