What context does the scheduler code run in?

Question

There are two cases where the scheduler code schedule() is invoked-

When a process voluntarily calls schedule()
Timer interrupt calls schedule()

In case 2, I think schedule() runs in interrupt context, but what about the first case? Does it run in the context of the process which invoked it?

Also are there any more scenarios which invoke schedule()?

There's another case in which schedule() will be invoked: when a process blocks (for example due to I/O operation). — omer, Sep 30 '15 at 10:39
@omer It is the timer interrupt that call schedule() when process blocks. so your case is the same to case 2 — baotiao, Jun 15 '17 at 08:08

score 9 · Accepted Answer · answered Aug 18 '11 at 11:14

9

schedule() always runs in process context. In the second case, when it is initiated by a timer interrupt, it is in the return path back from the kernel to the interrupted process where schedule() is called.

answered Aug 18 '11 at 11:14

caf

233,326
40
323
462

Well schedule() happens as a system call which is just a trap interrupt AFAIK right? – Jesus Ramos Aug 19 '11 at 00:22
@Jesus Ramos: "process context" and "interrupt context" are Linux kernel development terms that describe the context of code that is executing in kernel space: whether it can be regarded as executing on behalf of a particular process (as in a system call) or alteratively servicing a hardware interrupt. – caf Aug 19 '11 at 01:02
Yeah I know the terminology the thing is that it was kind of confusing in this sense because a system call is technically an interrupt so I'm not sure if that's what he meant or the way the call actually gets executed. – Jesus Ramos Aug 19 '11 at 01:09
4

@Jesus Ramos: It doesn't make sense to categorise things on how the kernel was entered, because it's *always* entered by means of an interrupt of some sort. `schedule()` itself is always a codepath executing on behalf of the process to be scheduled-out, even if the kernel was entered via a timer interrupt - which means process context. – caf Aug 19 '11 at 01:27
@JesusRamos: anyway, the traditional (non-Intel) terminology would be: interrupt (from a device), trap/syscall (from software), exception/fault (any of the former + from the CPU). Intel would be: exception/fault (from CPU), interrupt(from anywhere). – ninjalj Feb 23 '12 at 20:55

score 2 · Answer 2 · answered Sep 04 '13 at 20:19

__schedule() is the main scheduler function.

The main means of driving the scheduler and thus entering this function are:

Explicit blocking: mutex, semaphore, waitqueue, etc.
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().
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_PREEMPT=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_PREEMPT 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

http://lxr.free-electrons.com/source/kernel/sched/core.c#L2389

score 0 · Answer 3 · edited Jul 08 '13 at 14:52

When a process calls schedule() it runs in a system call context which is interrupt based. In the 2nd case a hardware interrupt triggers the schedule() call. In both cases it runs as an interrupt. AFAIK those are the only times that schedule() is called because most manipulation of scheduling involves modifying the kernel run queue of things to be scheduled although a process can be interrupted but that is usually done via an interrupt to tell the process to yield or the process yielding itself.

What context does the scheduler code run in?

3 Answers3

Linked