Messages in this thread | | | Date | Fri, 02 Sep 2011 14:18:11 +0800 | From | Shan Hai <> | Subject | Re: General question about TASK_INTERRUPTIBLE and schedule_timeout() |
| |
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/
| |