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@xxxxxx> > 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@xxxxxxxxxxxxxxxxxxxx> >> 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@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
