Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()

[kautuk.c @samsung.com]

I forgot to mention one example of this:
In arch/arm/kernel/entry-armv.S, we the preempt_schedule_irq function
is called to schedule
another task as part of kernel preemption.
This function will set PREMPT_ACTIVE before calling schedule().

In schedule(), the interrupted task will not be removed from the
runqueue as the if () condition
ealuates to false, which does not allow the deactivate_task() to be called

On Fri, Sep 2, 2011 at 1:01 PM, kautuk.c @samsung.com
<consul.kautuk@xxxxxxxxx> wrote:
> On Fri, Sep 2, 2011 at 12:36 PM, Shan Hai <haishan.bai@xxxxxxxxx> wrote:
>> On 09/02/2011 02:18 PM, Shan Hai wrote:
>>>
>>> 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
>
> Yes.
>
>>>
>>> and the pick_next_task() might put the preempted task to sleep.
>>>
>
> pick_next_task() will simply select the next task for scheduling.
> After all running tasks have been scheduled then this preempted task
> will also be rescheduled
> as it is still on this runqueue.
>
> I do not think that this will put this preempted it to sleep.
> Reason: Although the state is still set to TASK_INTERRUPTIBLE, the
> task is not removed
> from the runqueue as !(preempt_count() & PREEMPT_ACTIVE) == false.
>
>
>>
>> I mean when the state of task is TASK_INTERRUPTIBLE the preempted task will
>> be put to sleep, its true in sifram's case.
>
> I disagree.Yong is still right in this scenario as the task will
> remain on the runqueue due to
> the !(preempt_count() & PREEMPT_ACTIVE) == false.
>
>>
>> Yong is right on stating "schedule() will not put an preempted task to
>> sleep",
>> its true for the task state of which is TASK_RUNNING.
>
> Since TASK_RUNNING is defined as 0, the task remains on the runqueue here also.
>
>>
>> Cheers
>> Shan Hai
>>
>>> 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/
>>>
>>
>> --
>> 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/
>>
>
--
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/