sched: Document schedule() entry points
PATCH 1/1 sched: Document schedule() entry points
This patch adds a comment on top of the schedule() function to explain to scheduler newbies how the main scheduler function is entered.
Explained-by Ingo Molnar <[email protected]>
Explained-by Peter Zijlstra <[email protected]>
Signed-off-by Pekka Enberg <[email protected]>
--- kernel/sched/core.c | 34 ++++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-)
kernel/sched/core.c +34 -0
@@ -3361,6 +3361,40 @@ pick_next_task(struct rq *rq)/* * __schedule() is the main scheduler function. +* +* 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 is set +* 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_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 */ static void __sched __schedule(void) {
Signature · 1 line
1.7.7.6
Quoted 17 lines · Pekka Enberg
This patch adds a comment on top of the
schedule()function to explain to scheduler newbies how the main scheduler function is entered.Explained-by Ingo Molnar <[email protected]>Explained-by Peter Zijlstra <[email protected]>Signed-off-by Pekka Enberg <[email protected]>--- kernel/sched/core.c | 34 ++++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-)kernel/sched/core.c +0
-0@@ -3361,6 +3361,40 @@ pick_next_task(struct rq *rq)/*
kernel/sched/core.c pick_next_task(struct rq *rq) · line 3372
Quoted 10 lines
kernel/sched/core.c +9
-0* __schedule() is the main scheduler function. +* +* 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 is set
eh?
Quoted 28 lines
kernel/sched/core.c +25
-0+* 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_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 */ static void __sched __schedule(void) {
Signature · 1 line
~Randy