Hung Task Timeout

[manishrma@gmail.com (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