Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()

[Shan Hai <haishan.bai@gmail.com>]

On 09/01/2011 10:09 AM, Yong Zhang wrote:
> On Wed, Aug 31, 2011 at 06:18:19PM +0530, sifram rajas wrote:
>> Hi,
>>
>> 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.
> Yes.
>
>> 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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/