OK. I got it. schedule() -> reacquire_kernel_lock() -> down() -> might_sleep(). The latest (most nested) method will yield cond_resched() in a voluntary-preemptive kernel. But in a full-preemptive kernel, might_sleep() yields nothing more than debug. So the above basically explains my question on PREEMPT_ACTIVE. But it seems confirm my suspicious that cond_resched() should be implemented as no-op in a full-preemptive kernel. Is my reasoning correct? 2007/2/22, Dong Feng <middle.fengdong@xxxxxxxxx>:
I have seen that comments, too. And more comments at: http://lkml.org/lkml/2006/12/26/62. One wired thing is that I can not discover the recursive twice call to cond_resched() in the code mentioned by both places. Could any one help out point out it? Thanks a lot. 2007/2/22, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>: > Hi... > > I think I made mistake... > > I see comments like this: > > *//*/*/* The BKS might be reacquired before we have dropped/* > */ PREEMPT_ACTIVE, which could trigger a second/* > */* cond_resched() call.*//* > > I don't know what BKS is, maybe it means BKL. In that case, > without looking into the actual codes, I guess while BKL is > reacquired, it implicitly call cond_resched(). That's the > 2nd "hidden" cond_resched. I hope I do it correctly this time. > > regards, > > Mulyadi > >
-- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
