Kernel thread scheduling
Hello, I am actually studying kernel threads, and I have some doubts about them. Let's take for example this snippet of code static int thread_function(void *data) { while (!kthread_should_stop()) { schedule(); } pr_err("Stopped"); return 0; } This way it works just fine, and waits until I call kthread_stop on it. But if I comment out that schedule() call, it just hangs my system when I load it (it is part of a module). I see that the loop-schedule-wakeup pattern is used among all the others kernel threads. But I don't get why I need to call the scheduler explicitly. I know that the kernel is fully preemptible, and in my interpretation I thought that it could stop every running thread, even in kernel space, using a timer-based interrupt handler, to give cpu to other threads. Doesn't this pattern resemble a voluntary preemption model? Where am I wrong?
-----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Vincenzo Scotti Sent: Friday, March 20, 2015 4:20 PM To: kernelnewbies@kernelnewbies.org Subject: Kernel thread scheduling Hello, I am actually studying kernel threads, and I have some doubts about them. Let's take for example this snippet of code static int thread_function(void *data) { while (!kthread_should_stop()) { schedule(); } pr_err("Stopped"); return 0; } This way it works just fine, and waits until I call kthread_stop on it. But if I comment out that schedule() call, it just hangs my system when I load it (it is part of a module). I see that the loop-schedule-wakeup pattern is used among all the others kernel threads. But I don't get why I need to call the scheduler explicitly. I know that the kernel is fully preemptible, and in my interpretation I thought that it could stop every running thread, even in kernel space, using a timer-based interrupt handler, to give cpu to other threads. Doesn't this pattern resemble a voluntary preemption model? Where am I wrong? Are you sure your kernel is configured with kernel preemption on? It is a configurable option. Grep for PREEMPT in your .config file. Jeff
Hi Jeff, kernel_thread just like daemon process. These are self monitoring process. These process get scheduled by the kernel when their is any state change from TASK_INTERRUPTIBLE to TASK_RUNNING or their is some condition that get full field. If you don't schedule() the kernel thread state is not get updated by the scheduler. Below example can help clear the concept. http://lxr.free-electrons.com/source/drivers/vhost/vhost.c#L225 -Anand Moon On Saturday, March 21, 2015 4:58 AM, Jeff Haran <Jeff.Haran@citrix.com> wrote: -----Original Message----- From: kernelnewbies-bounces@kernelnewbies.org [mailto:kernelnewbies-bounces@kernelnewbies.org] On Behalf Of Vincenzo Scotti Sent: Friday, March 20, 2015 4:20 PM To: kernelnewbies@kernelnewbies.org Subject: Kernel thread scheduling Hello, I am actually studying kernel threads, and I have some doubts about them. Let's take for example this snippet of code static int thread_function(void *data) { while (!kthread_should_stop()) { schedule(); } pr_err("Stopped"); return 0; } This way it works just fine, and waits until I call kthread_stop on it. But if I comment out that schedule() call, it just hangs my system when I load it (it is part of a module). I see that the loop-schedule-wakeup pattern is used among all the others kernel threads. But I don't get why I need to call the scheduler explicitly. I know that the kernel is fully preemptible, and in my interpretation I thought that it could stop every running thread, even in kernel space, using a timer-based interrupt handler, to give cpu to other threads. Doesn't this pattern resemble a voluntary preemption model? Where am I wrong? Are you sure your kernel is configured with kernel preemption on? It is a configurable option. Grep for PREEMPT in your .config file. Jeff _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Thank you for the example. I understand what are the scheduling mechanics depending on task->state. But suppose another situation. Let's say I change current state to TASK_INTERRUPTIBLE. If I start now some long operation, then shouldn't the scheduler kick in as soon as he can and put my thread asleep? Or should I call necessarily schedule()? And if so, why?
On 2015-03-22 07:14 PM, Vincenzo Scotti wrote:
Thank you for the example.
I understand what are the scheduling mechanics depending on task->state. But suppose another situation. Let's say I change current state to TASK_INTERRUPTIBLE. If I start now some long operation, then shouldn't the scheduler kick in as soon as he can and put my thread asleep? Or should I call necessarily schedule()? And if so, why?
Greetings Vincenzo. I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love as when I was learning the scheduler and process management for the kernel,I found these chapters to be very useful.Further more for user space you are correct to my knowledge schedule is called for internal tasks that are taking too long in kernel land or to reschedule to another task,not for user space based tasks are TASK_INTERRUPTIBLE works fine there. Hope this Helps, Nick _______________________________________________
Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 03/22/2015 07:30 PM, nick wrote:
I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love as when I was learning the scheduler and process management
how much has the scheduler changed since then. It was completely overhauled when the CFS was created
On 2015-03-22 08:05 PM, Ruben Safir wrote:
On 03/22/2015 07:30 PM, nick wrote:
I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love as when I was learning the scheduler and process management
how much has the scheduler changed since then. It was completely overhauled when the CFS was created
The 3rd edition of this book was written after CFS was in the kernel so the chapters are pretty up to date. Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
It is passover so I've read over much of this text, but I have to say that in general, I'm way ahead of this book. Although I have limited knowledge of Kernel technology in the specific, the C code, data structs, and programming concepts are spoon feed in this text and its wasting too much time with words that are more easily explained with coding examples and UML charts. I don't need a chapter explaining how to use ps and the basis of Unix architecture. This text is targeted to a different audience, and FWIW, I'm not certain it does a good job of that either. The guys who write these texts fall in love with their own voices. I know, I've suffered this disease myself when I've written tech articles and books. I can''t recommend this book to anyone. Anyone who doesn't understand the basics of I/O processer blocks is not going to understand static void update_curr(struct cfs_rq *cfs_rq) and OTOH void update_curr(struct cfs_rq *cfs_rq) is not explained well enough for coders unfamiliar with the kernel data structs of which BTW struct cfs_rq is not one defined in the text. :( I'm looking for something more like this, but flushed out more as a textbook http://www.ibm.com/developerworks/library/l-completely-fair-scheduler/index...., and some mentoring, I hope. Ruben On 03/22/2015 08:35 PM, nick wrote:
On 2015-03-22 08:05 PM, Ruben Safir wrote:
On 03/22/2015 07:30 PM, nick wrote:
I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love as when I was learning the scheduler and process management
how much has the scheduler changed since then. It was completely overhauled when the CFS was created
The 3rd edition of this book was written after CFS was in the kernel so the chapters are pretty up to date. Nick
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
.
participants (5)
-
Anand Moon -
Jeff Haran -
nick -
Ruben Safir -
Vincenzo Scotti