Re: Kernel thread scheduling

2015-03-22 Thread Vincenzo Scotti
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?


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Kernel thread scheduling

2015-03-20 Thread Vincenzo Scotti
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?

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies