Thanks a lot for replying. 2007/2/22, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>:
Hi... > I have a couple of questions regarding cond_resched(). > > The first one is: what's the motivation to introduce this function? IMHO, it prevents user from incorrectly calling schedule() in atomic or can-not-be-preempted situation.
I have not seen any code in cond_resched() to do more check than schedule() in this regard. Does it do that anywhere I missed?
Also, by checking for need_resched(), it only schedules if the current task is really told to be kicked out. This will save TLB flush in certain condition i.e switching between full processes, not threads
If this is the reason to invoke cond_resched(), then I feel cond_resched() is only useful in a voluntary-preemption-only kernel (i.e. PREEMPT_VOLUNTARY is set but PREEMPT is not set). In a full preemptive kernel, I think a process need to be rescheduled will be rescheduled immediately when an interrupt occurs so an explicit invocation to cond_resched() is unnecessary. Does my reasoning miss anything?
> > The second question is, why the cond_resched() have > PREEMPT_ACTIVE > flag set before calling schedule()? The comments seems to say > it is to > prevent a second (recursive?) call of cond_resched(), but I can > not > see any recursive call in the source code. Did I miss anything? Well, since it is a preventive act and likely everybody knows that he/she should avoid recursive cond_resched() invocation, then you see none. But of course, someday somebody could make mistake related to this issue, this is where the safeguard kicks in :) 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
