On 09/01/2011 10:09 AM, Yong Zhang wrote:On Wed, Aug 31, 2011 at 06:18:19PM +0530, sifram rajas wrote:Hi,Yes.
I have a general question about the following 2 lines of code I see
all over the kernel:
1 set_current_state(TASK_INTERRUPTIBLE) ;
2 schedule_timeout(<some value>);
In the above code, if we encounter an interrupt after executing line
1, we will end up
call schedule() from the architecture specific code for CONFIG_PREEMPT
kernels, after
the interrupt handler has been invokled.
This will cause the current task to sleep interruptibly forever
Actually, sleeping forever in the TASK_INTERRUPTIBLE state is not correct,
because even though the task is preempted by higher priority one
it will finally get a chance to run, but you will get time out value
of <some value> + preemption latency.
instead of for a certain timeout interval.No.
schedule() will not put an preempted task to sleep, see:
This might be problematic, because on the IRQ to preemption check path
the PREEMPT_ACTIVE was already set and the following 'if' statement
could not hold because of
!(preempt_count() & PREEMPT_ACTIVE) == false
and the pick_next_task() might put the preempted task to sleep.
Correct me on any misunderstanding :-)
Cheers
Shan Hai
asmlinkage void __sched schduule(void)
{
...
if (prev->state&& !(preempt_count()& PREEMPT_ACTIVE)) {
if (unlikely(signal_pending_state(prev->state, prev))) {
prev->state = TASK_RUNNING;
} else {
...
}
}
...
}
Thanks,
Yong
Won't this defeat the purpose of the above code to schedule out or
sleep for a certain finite timeout ?
If yes, then what are the techniques to solve this problem ?
Thanks,
Sifram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/