From: Randy Dunlap <rdunlap@xenotime.net>
To: Pekka Enberg <penberg@kernel.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org
Subject: Re: [PATCH] sched: Document schedule() entry points
Date: Tue, 31 Jul 2012 10:25:04 -0700 [thread overview]
Message-ID: <501814F0.5050008@xenotime.net> (raw)
In-Reply-To: <1343715300-6315-1-git-send-email-penberg@kernel.org>
On 07/30/2012 11:15 PM, Pekka Enberg wrote:
> 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 <mingo@kernel.org>
> Explained-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Pekka Enberg <penberg@kernel.org>
> ---
> kernel/sched/core.c | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 468bdd4..9f31bbd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -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
eh?
> + * 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)
> {
--
~Randy
prev parent reply other threads:[~2012-07-31 17:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 6:15 [PATCH] sched: Document schedule() entry points Pekka Enberg
2012-07-31 17:25 ` Randy Dunlap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501814F0.5050008@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.