Hung Task Timeout

Mani,

On Tue, Apr 17, 2012 at 1:35 PM, mani [off-list ref] 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