sched: Document schedule() entry points
PATCH v2 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.
---
V1 -> V2: Fix funky grammar pointed out by Peter and Randy.
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 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 9 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.Cc Randy Dunlap <[email protected]>Explained-by Ingo Molnar <[email protected]>Explained-by Peter Zijlstra <[email protected]>Signed-off-by Pekka Enberg <[email protected]>---
V1 -> V2: Fix funky grammar pointed out by Peter and Randy.
Ack. Thanks.
Quoted 48 lines
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 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
Commit-ID: 7cbcdf58442fe7bf477d549be92329e22e64b146 Gitweb: http://git.kernel.org/tip/7cbcdf58442fe7bf477d549be92329e22e64b146 Author: Pekka Enberg <[email protected]> AuthorDate: Sat, 4 Aug 2012 11:49:47 +0300 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 13 Aug 2012 18:51:59 +0200
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.
--- 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 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) {
Commit-ID: edde96eafc91a510f404e7b82cfc0ecb608505ee Gitweb: http://git.kernel.org/tip/edde96eafc91a510f404e7b82cfc0ecb608505ee Author: Pekka Enberg <[email protected]> AuthorDate: Sat, 4 Aug 2012 11:49:47 +0300 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 13 Aug 2012 18:58:15 +0200
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.
--- kernel/sched/core.c | 34 ++++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-)
kernel/sched/core.c +34 -0
@@ -3367,6 +3367,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 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) {