Hung Task Timeout

[p.ittershagen@googlemail.com (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