* General question about TASK_INTERRUPTIBLE and schedule_timeout()
@ 2011-08-31 12:48 sifram rajas
2011-08-31 13:05 ` sifram rajas
2011-09-01 2:09 ` Yong Zhang
0 siblings, 2 replies; 8+ messages in thread
From: sifram rajas @ 2011-08-31 12:48 UTC (permalink / raw)
To: linux-kernel
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.
This will cause the current task to sleep interruptibly forever
instead of for a certain timeout interval.
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-08-31 12:48 General question about TASK_INTERRUPTIBLE and schedule_timeout() sifram rajas
@ 2011-08-31 13:05 ` sifram rajas
2011-09-01 2:09 ` Yong Zhang
1 sibling, 0 replies; 8+ messages in thread
From: sifram rajas @ 2011-08-31 13:05 UTC (permalink / raw)
To: linux-kernel
Hi,
If this is a problem, then can this be solved by disabling preemption
in the following
manner ? :
preempt_disable() ;
set_current_state(TASK_INTERRUPTIBLE) ;
schedule_timeout(<some value>);
preempt_enable() ;
On Wed, Aug 31, 2011 at 6:18 PM, sifram rajas <sifram.rajas@gmail.com> 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.
>
> This will cause the current task to sleep interruptibly forever
> instead of for a certain timeout interval.
>
> 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.
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-08-31 12:48 General question about TASK_INTERRUPTIBLE and schedule_timeout() sifram rajas
2011-08-31 13:05 ` sifram rajas
@ 2011-09-01 2:09 ` Yong Zhang
2011-09-02 6:18 ` Shan Hai
1 sibling, 1 reply; 8+ messages in thread
From: Yong Zhang @ 2011-09-01 2:09 UTC (permalink / raw)
To: sifram rajas; +Cc: linux-kernel
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
> instead of for a certain timeout interval.
No.
schedule() will not put an preempted task to sleep, see:
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/
--
Only stand for myself
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-09-01 2:09 ` Yong Zhang
@ 2011-09-02 6:18 ` Shan Hai
2011-09-02 7:06 ` Shan Hai
0 siblings, 1 reply; 8+ messages in thread
From: Shan Hai @ 2011-09-02 6:18 UTC (permalink / raw)
To: Yong Zhang; +Cc: sifram rajas, linux-kernel
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-09-02 6:18 ` Shan Hai
@ 2011-09-02 7:06 ` Shan Hai
2011-09-02 7:31 ` kautuk.c @samsung.com
0 siblings, 1 reply; 8+ messages in thread
From: Shan Hai @ 2011-09-02 7:06 UTC (permalink / raw)
To: Yong Zhang; +Cc: sifram rajas, linux-kernel
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
>
> and the pick_next_task() might put the preempted task to sleep.
>
I mean when the state of task is TASK_INTERRUPTIBLE the preempted task will
be put to sleep, its true in sifram's case.
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.
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@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-09-02 7:06 ` Shan Hai
@ 2011-09-02 7:31 ` kautuk.c @samsung.com
2011-09-02 7:44 ` kautuk.c @samsung.com
2011-09-02 8:08 ` Shan Hai
0 siblings, 2 replies; 8+ messages in thread
From: kautuk.c @samsung.com @ 2011-09-02 7:31 UTC (permalink / raw)
To: Shan Hai; +Cc: Yong Zhang, sifram rajas, linux-kernel
On Fri, Sep 2, 2011 at 12:36 PM, Shan Hai <haishan.bai@gmail.com> 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@vger.kernel.org
>>>> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-09-02 7:31 ` kautuk.c @samsung.com
@ 2011-09-02 7:44 ` kautuk.c @samsung.com
2011-09-02 8:08 ` Shan Hai
1 sibling, 0 replies; 8+ messages in thread
From: kautuk.c @samsung.com @ 2011-09-02 7:44 UTC (permalink / raw)
To: Shan Hai; +Cc: Yong Zhang, sifram rajas, linux-kernel
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@gmail.com> wrote:
> On Fri, Sep 2, 2011 at 12:36 PM, Shan Hai <haishan.bai@gmail.com> 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@vger.kernel.org
>>>>> 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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: General question about TASK_INTERRUPTIBLE and schedule_timeout()
2011-09-02 7:31 ` kautuk.c @samsung.com
2011-09-02 7:44 ` kautuk.c @samsung.com
@ 2011-09-02 8:08 ` Shan Hai
1 sibling, 0 replies; 8+ messages in thread
From: Shan Hai @ 2011-09-02 8:08 UTC (permalink / raw)
To: kautuk.c @samsung.com; +Cc: Yong Zhang, sifram rajas, linux-kernel
On 09/02/2011 03:31 PM, kautuk.c @samsung.com wrote:
> On Fri, Sep 2, 2011 at 12:36 PM, Shan Hai<haishan.bai@gmail.com> 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.
>
>
Yep, that's right, call 'sleep' here is improper, the right way
to put it should be 'the current task is deprived of its CPU' OR
'the current lost the CPU', we call sleep when a task is
removed from the run queue anyway :-)
>> 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.
>
As stated above.
Cheers
Shan Hai
>> 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@vger.kernel.org
>>>>> 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@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-09-02 8:09 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-31 12:48 General question about TASK_INTERRUPTIBLE and schedule_timeout() sifram rajas
2011-08-31 13:05 ` sifram rajas
2011-09-01 2:09 ` Yong Zhang
2011-09-02 6:18 ` Shan Hai
2011-09-02 7:06 ` Shan Hai
2011-09-02 7:31 ` kautuk.c @samsung.com
2011-09-02 7:44 ` kautuk.c @samsung.com
2011-09-02 8:08 ` Shan Hai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox