-1

Is the process scheduler "visible" at user space? Can I see it with ps? Maybe is it one of the kernel threads? If yes, how is it called? How can I "see" it?

It doesn’t exist as a separate thread, or module, it’s implemented as a function

Ok, but how and where and in which way is this function run? Is there a way to track it and see it?

1
  • A common metaphor is to think of the system as a plate of spaghetti. The threads are, naturally, the strands of spaghetti; the scheduler is the sauce. Apr 21, 2022 at 1:22

1 Answer 1

1

As explained in What's the process scheduler in Linux? the scheduler is a kernel function, __schedule; it doesn’t appear as a separate thread or process.

The function comment explains how it is run:

 * The main means of driving the scheduler and thus entering this function are:
 *
 *   1. Explicit blocking: mutex, semaphore, waitqueue, etc.
 *
 *   2. TIF_NEED_RESCHED flag is checked on interrupt and userspace return
 *      paths. For example, see arch/x86/entry_64.S.
 *
 *      To drive preemption between tasks, the scheduler sets the flag in timer
 *      interrupt handler scheduler_tick().
 *
 *   3. Wakeups don't really cause entry into schedule(). They add a
 *      task to the run-queue and that's it.
 *
 *      Now, if the new task added to the run-queue preempts the current
 *      task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
 *      called on the nearest possible occasion:
 *
 *       - If the kernel is preemptible (CONFIG_PREEMPTION=y):
 *
 *         - in syscall or exception context, at the next outmost
 *           preempt_enable(). (this might be as soon as the wake_up()'s
 *           spin_unlock()!)
 *
 *         - in IRQ context, return from interrupt-handler to
 *           preemptible context
 *
 *       - If the kernel is not preemptible (CONFIG_PREEMPTION is not set)
 *         then at the next:
 *
 *          - cond_resched() call
 *          - explicit schedule() call
 *          - return from syscall or exception to user-space
 *          - return from interrupt-handler to user-space

The function can’t be traced; its instrumentation is disabled (see the notrace entry in its declaration).

9
  • if it is a kernel function, the kernel is "invisible"...? Does it fight against other processes/threads for cpu time? How is being executed?
    – Allexj
    Apr 16, 2022 at 14:24
  • 1
    The kernel isn’t invisible, it’s the “system” part of CPU time (e.g. in top). Kernel code is executed whenever a process calls it (through a system call) or whenever an interrupt occurs. It doesn’t fight with processes for CPU time, it enables processes to do their work. Apr 16, 2022 at 14:28
  • 1
    Run top, and look at the “sy” value in the “%Cpu(s)” line — that’s the system time, “sy, system: time running kernel processes” (in the top man page). You’d also need to add “hi” and “si”, the time spent servicing interrupts. IIRC this doesn’t count the time spent handling system calls; that’s done in service of the calling process and counted against that process. You can see the time spent in system calls by running time. Apr 16, 2022 at 14:40
  • 1
    OK, so yes, the time spent running the kernel is time not available to run user processes, but it’s handling essential work so I don’t really see it as a fight; in other words, the system can’t choose not to run the kernel when it needs to, otherwise nothing else happens. sy covers time spent in kernel threads, which are visible as processes; they are all children of the kthreadd process (pid 2). Apr 16, 2022 at 15:37
  • 1
    The scheduler is a small part of the kernel. It doesn’t show up as a kernel thread, but other tasks in the kernel are handled as threads. My comment about the kernel not being invisible was about the kernel as a whole. Apr 16, 2022 at 16:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .