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 < [email protected]> wrote: > Mani, > > On Tue, Apr 17, 2012 at 1:35 PM, mani <[email protected]> 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 >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
