Hung Task Timeout

Hung Task Timeout

[mani]

Hi All,

How kernel scheduler treats task's TASK_UNINTERRUPTIBLE &
TASK_INTERREPTIBLE states ?

Actually in my case i have created a kernel thread and it is waiting on an
event as per below :-

wait_event(queue, flag);

in the above condition it gives me hung task timeout dump as it puts the
task in TASK_UNINTERRUPTIBLE state
whereas if i change the function call to

wait_event_interruptible(queue, flag);
It works fine as the task is in TASK_INTERREPTIBLE state

I have checked in the kernel [kernel/hung_task.c ] check_hung_task()
It says that

    /*
     * Ok, the task did not get scheduled for more than 2 minutes,
     * complain:
     */
So is that means that TASK_UNINTERRUPTIBLE will not get schedule by the
scheduler ?
Can anyone give the detail information what's going on in backyard ?


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120417/431df745/attachment.html 

Hung Task Timeout

[Philipp Ittershagen]

On Tue, Apr 17, 2012 at 6:26 AM, mani <manishrma@gmail.com> wrote:
> So is that means that TASK_UNINTERRUPTIBLE will not get schedule by the
> scheduler ?
> Can anyone give the detail information what's going on in backyard ?

An explanation of the different states is given in [1]:

A process can sleep in two different modes, interruptible and
uninterruptible. In an interruptible sleep, the process could be woken
up for processing of signals. In an uninterruptible sleep, the process
could not be woken up other than by issuing an explicit wake_up.
Interruptible sleep is the preferred way of sleeping, unless there is
a situation in which signals cannot be handled at all, such as device
I/O.

So, unless you absolutely cannot handle singals, you should use
TASK_INTERRUPTIBLE and check for signals using signal_pending() (many
code examples use this in the ldd3 book).

TASK_UNINTERRUPTIBLE consequently means that your thread is not
scheduled unless you explicitly wake up the thread.


Greetings,

  Philipp

[1]: http://www.linuxjournal.com/article/8144?page=0,0

Hung Task Timeout

[mani]

Thanks Philipp for the explanation and the link.

But i Still have the same question:-

*Do scheduler schedule the tasks with TASK_INTERRUPTIBLE state **? *
As i know TASK_UNINTERRUPTIBLE & TASK_INTERRUPTIBLE  both are not in the
run queue
and so both type of tasks should not being scheduled by the scheduler.
If YES, then why it is needed to schedule task in TASK_INTERRUPTIBLE state ?

What is the significance of the task->switch_count in the scheduler ?
surely it got updated for the TASK_INTERRUPTIBLE task.
[kernel/hung_task.c]check_hung_task()

Thanks
Mani


On Tue, Apr 17, 2012 at 1:06 PM, Philipp Ittershagen <
p.ittershagen@googlemail.com> wrote:

> On Tue, Apr 17, 2012 at 6:26 AM, mani <manishrma@gmail.com> wrote:
> > So is that means that TASK_UNINTERRUPTIBLE will not get schedule by the
> > scheduler ?
> > Can anyone give the detail information what's going on in backyard ?
>
> An explanation of the different states is given in [1]:
>
> A process can sleep in two different modes, interruptible and
> uninterruptible. In an interruptible sleep, the process could be woken
> up for processing of signals. In an uninterruptible sleep, the process
> could not be woken up other than by issuing an explicit wake_up.
> Interruptible sleep is the preferred way of sleeping, unless there is
> a situation in which signals cannot be handled at all, such as device
> I/O.
>
> So, unless you absolutely cannot handle singals, you should use
> TASK_INTERRUPTIBLE and check for signals using signal_pending() (many
> code examples use this in the ldd3 book).
>
> TASK_UNINTERRUPTIBLE consequently means that your thread is not
> scheduled unless you explicitly wake up the thread.
>
>
> Greetings,
>
>  Philipp
>
> [1]: http://www.linuxjournal.com/article/8144?page=0,0
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120417/d194b146/attachment.html 

Hung Task Timeout

[Philipp Ittershagen]

Mani,

On Tue, Apr 17, 2012 at 1:35 PM, mani <manishrma@gmail.com> wrote:
> Thanks Philipp for the explanation and the link.
>
> But i Still have the same question:-
>
> Do scheduler schedule the tasks with TASK_INTERRUPTIBLE state ?
> As i know TASK_UNINTERRUPTIBLE & TASK_INTERRUPTIBLE? both are not in the run
> queue
> and so both type of tasks should not being scheduled by the scheduler.
> If YES, then why it is needed to schedule task in TASK_INTERRUPTIBLE state ?

think of a signal as a software interrupt. If your thread is in the
TASK_INTERRUPTIBLE state, it can be woken up by such software
interrupt handlers in order to deliver the signal to your thread. Your
thread will then be put into the runqueue ( and state will be
TASK_RUNNING) and your wait_event_interruptible() call will return
with the value -ERESTARTSYS. This is for you to be able to react to
the delivered signal (you can read the active signals using
signal_pending(current)). So, to answer your question: Yes, your
thread will be put back into the runqueue, if you mark it as
TASK_INTERRUPTIBLE and a signal is delivered to your thread. Your
thread will _not_ be interrupted by software interrupts/signals when
you mark it as TASK_UNINTERRUPTIBLE.


> What is the significance of the task->switch_count in the scheduler ?
> surely it got updated for the TASK_INTERRUPTIBLE task.
> [kernel/hung_task.c]check_hung_task()

You can see in the same source file that check_hung_task() is called
by check_hung_uninterruptible_tasks(). But the function
check_hung_task() is only called for tasks which are in the state
TASK_UNINTERRUPTIBLE:

   if (t->state == TASK_UNINTERRUPTIBLE)
         check_hung_task(t, timeout);

The t->last_switch_count counts the number of switches since the last
call to check_hung_task() (the value is only updated there).

I hope this answers your questions.


Greetings,

  Philipp

Hung Task Timeout

[mani]

Thanks Phillip its more clear now

This is the point i missed
*You can see in the same source file that check_hung_task() is called
by check_hung_uninterruptible_tasks(). But the function
check_hung_task() is only called for tasks which are in the state
TASK_UNINTERRUPTIBLE:
*
>
> *   if (t->state == TASK_UNINTERRUPTIBLE)
>         check_hung_task(t, timeout);*
>

So if i changed the above check to the TASK_INTERRUPTIBLE then i will get
the hung_task_timeout for TASK_INTERRUPTIBLE task also.

*"Yes, your thread will be put back into the runqueue, if you mark it as
TASK_INTERRUPTIBLE and a signal is delivered to your thread"*

I think in my case both the tasks wait in the wait_queue and never come to
the TASK_RUNNING state.
In case of the TASK_INTERRUPTIBLE, it will get scheduled (or put to run
queue) in two cases only:-
1. If it receive any signal not before that (we are not sending any signal
to the task so it will remain in the wait_queue)
2. we call a wake_up () call.
otherwise there is no point in putting the task in run queue which has
nothing to do.

Thanks,
Mani


On Tue, Apr 17, 2012 at 6:16 PM, Philipp Ittershagen <
p.ittershagen@googlemail.com> wrote:

> Mani,
>
> On Tue, Apr 17, 2012 at 1:35 PM, mani <manishrma@gmail.com> wrote:
> > Thanks Philipp for the explanation and the link.
> >
> > But i Still have the same question:-
> >
> > Do scheduler schedule the tasks with TASK_INTERRUPTIBLE state ?
> > As i know TASK_UNINTERRUPTIBLE & TASK_INTERRUPTIBLE  both are not in the
> run
> > queue
> > and so both type of tasks should not being scheduled by the scheduler.
> > If YES, then why it is needed to schedule task in TASK_INTERRUPTIBLE
> state ?
>
> think of a signal as a software interrupt. If your thread is in the
> TASK_INTERRUPTIBLE state, it can be woken up by such software
> interrupt handlers in order to deliver the signal to your thread. Your
> thread will then be put into the runqueue ( and state will be
> TASK_RUNNING) and your wait_event_interruptible() call will return
> with the value -ERESTARTSYS. This is for you to be able to react to
> the delivered signal (you can read the active signals using
> signal_pending(current)). So, to answer your question: Yes, your
> thread will be put back into the runqueue, if you mark it as
> TASK_INTERRUPTIBLE and a signal is delivered to your thread. Your
> thread will _not_ be interrupted by software interrupts/signals when
> you mark it as TASK_UNINTERRUPTIBLE.
>
>
> > What is the significance of the task->switch_count in the scheduler ?
> > surely it got updated for the TASK_INTERRUPTIBLE task.
> > [kernel/hung_task.c]check_hung_task()
>
> You can see in the same source file that check_hung_task() is called
> by check_hung_uninterruptible_tasks(). But the function
> check_hung_task() is only called for tasks which are in the state
> TASK_UNINTERRUPTIBLE:
>
>   if (t->state == TASK_UNINTERRUPTIBLE)
>         check_hung_task(t, timeout);
>
> The t->last_switch_count counts the number of switches since the last
> call to check_hung_task() (the value is only updated there).
>
> I hope this answers your questions.
>
>
> Greetings,
>
>  Philipp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120418/e3a0a4ab/attachment.html 

Hung Task Timeout

[Philipp Ittershagen]

On Wed, Apr 18, 2012 at 01:01:45PM +0530, mani wrote:
> I think in my case both the tasks wait in the wait_queue and never come to
> the TASK_RUNNING state.
> In case of the TASK_INTERRUPTIBLE, it will get scheduled (or put to run
> queue) in two cases only:-
> 1. If it receive any signal not before that (we are not sending any signal
> to the task so it will remain in the wait_queue)
> 2. we call a wake_up () call.
> otherwise there is no point in putting the task in run queue which has
> nothing to do.

Yes, correct. You should use TASK_INTERRUPTIBLE here, otherwise your kernel
thread cannot receive signals and you are not able to kill(1) your thread from
userspace or use kthread_stop() in the kernel.


Greetings,

  Philipp