Hi Peter, On Thu, 19 Nov 2009 14:06:54 +0100, Peter Zijlstra wrote: > On Thu, 2009-11-19 at 12:59 +0000, Alan Cox wrote: > > > Well, I guess only people monitoring system latency would notice, as > > > this is the only thing yield() was supposed to help with in the first > > > place. > > > > if (need_resched()) > > schedule(); > > aka. > > cond_resched(); Are you saying that most calls to yield() should be replaced with calls to cond_resched()? I admit I a little skeptical. While the description of cond_resched() ("latency reduction via explicit rescheduling in places that are safe") sounds promising, following the calls leads me to: static inline int need_resched(void) { return unlikely(test_thread_flag(TIF_NEED_RESCHED)); } So apparently the condition for need_resched() to do anything is considered unlikely... suggesting that cond_resched() is a no-op in most cases? I don't quite get the point of moving away from sched() because it is a no-op, if we end up with a no-op under a different name. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html