summaryrefslogtreecommitdiffstats
path: root/kernel/sched/core.c
diff options
context:
space:
mode:
authorPekka Enberg <penberg@kernel.org>2012-08-04 11:49:47 +0300
committerThomas Gleixner <tglx@linutronix.de>2012-08-13 18:58:15 +0200
commitedde96eafc91a510f404e7b82cfc0ecb608505ee (patch)
treece9c405422f4478c6a8910f4d0c512e939905e02 /kernel/sched/core.c
parent532b1858c5241bedfff5ab863d7cf012e8b81a6b (diff)
downloadlinux-stable-edde96eafc91a510f404e7b82cfc0ecb608505ee.tar.gz
linux-stable-edde96eafc91a510f404e7b82cfc0ecb608505ee.tar.bz2
linux-stable-edde96eafc91a510f404e7b82cfc0ecb608505ee.zip
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. Acked-by: Randy Dunlap <rdunlap@xenotime.net> Explained-by: Ingo Molnar <mingo@kernel.org> Explained-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1344070187-2420-1-git-send-email-penberg@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'kernel/sched/core.c')
-rw-r--r--kernel/sched/core.c34
1 files changed, 34 insertions, 0 deletions
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index fbf1fd098dc6..c9a3655e572d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -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)
{