|
@@ -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)
|
|
|
{
|