Re: when/how is the schedule() function actually called?

[iso m <isomorphik.ibm@gmail.com>]

On 08/12/23 11:51 pm, Dawei Li wrote:
> Hi Valdis,
> 
> Thanks for getting back to me!
> I should've looked into newer versions. (Was looking at 2.6.34 because the
> latest book I have on linux kernel, Linux
> Kernel Development, 3rd Edition by Robert Love, is based on that version.)
> 
> I do have the same question for the latest version.
> Here:
> https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe007d/kernel/sched/core.c#L5632
> the scheduler_tick() is calling curr->sched_class->task_tick(rq, curr, 0);
> https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe007d/kernel/sched/core.c#L5651
> This is calling entity_tick(),
> https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe007d/kernel/sched/fair.c#L5447
> and then resched_curr(),
> https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe007d/kernel/sched/core.c#L1040
> 
> As the comment says, resched_curr() is still just setting the need_resched
> flag on a uniprocessor.
> It is not calling the schedule() function.
> When/how is the schedule() function actually called?
I believe it's called at the code path (kernel -> user) and (kernel -> kernel)

Here, it'll be at return from the interrupt context.

Checkout point 2. in the following comment snippet found above __schedule()
method in kernel/sched/core.c

/*
 * __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_PREEMPTION=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_PREEMPTION 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
 *
 * WARNING: must be called with preemption disabled!
 */
static void __sched notrace __schedule(unsigned int sched_mode)


> 
> Appreciate any explanation/guidance on this!
> Thanks!
> 
> 
> On Sat, Dec 9, 2023 at 1:45 AM Valdis Klētnieks <valdis.kletnieks@vt.edu>
> wrote:
> 
>> On Sat, 09 Dec 2023 00:16:32 +0800, Dawei Li said:
>>> Greetings!
>>
>>> (Although I am using the 2.6.34 version, I believe the question is
>> generally
>>> applicable to any kernel version.)
>>
>> That is, in general, a bad assumption when you are looking at kernel
>> versions
>> old enough that they count as digital archaeology....
>>
>> [/usr/src/linux-next] git show v2.6.34
>> tag v2.6.34
>> Tagger: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Sun May 16 14:17:44 2010 -0700
>> [/usr/src/linux-next] git diff --shortstat  v2.6.34..next-20231205
>>  96965 files changed, 32056985 insertions(+), 7606202 deletions(-)
>>
>> Given that next-20231205 has just over 33 million lines of code, we're well
>> into territory where there's a vanishing small percentage of code still
>> remaining unchanged from 2010.
>>
>> And yes, that means that even basic functions schedule() and friends have
>> been
>> reworked in he past decade and a half....
>>
>>
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies