Hi, all, Does any one have any opinion with my thoughts? I all along compile kernel with full-preemption. I am curious why cond_resched() yield more than no-op under full-preemption option, since I think it is only useful in a voluntary-preemptive kernel. Thanks. Feng,Dong 2007/2/22, Dong Feng <middle.fengdong@xxxxxxxxx>:
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
