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/4df7c5fde316820286dfa6d203a1005d7fbe0... the scheduler_tick() is calling curr->sched_class->task_tick(rq, curr, 0); https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe0... This is calling entity_tick(), https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe0... and then resched_curr(), https://github.com/torvalds/linux/blob/4df7c5fde316820286dfa6d203a1005d7fbe0...
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