![]() | ||||||||||
Messages in this thread |
Bill Huey (hui) wrote: > > The might_sleep is annotation and well as a conditional preemption > point for the regular kernel. You might want to do a schedule check > there, but it's the wrong function if memory serves me correctly. It's > reserved for things that actually are design to sleep. Note that might_sleep() already does a cond_resched() on the configurations that need it, so I am not sure what you are getting at here. Is that not enough? > The rt_spin*() > function are really a method of preserving BKL semantics across real > schedule() calls. You'd have to use something else instead for that > purpose like cond_reschedule() instead. I dont quite understand this part either. From my perspective, rt_spin*() functions are locking constructs that might sleep (or might spin with the new patches), and they happen to be BKL and wakeup transparent. To me, either the might_sleep() is correct for all paths that don't fit the in_atomic-printk exception, or none of them are. Are you saying that the modified logic that I introduced is broken? Or that the original use of the might_sleep() annotation inside this function is broken? -Greg -- 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/ | |||||||||
| Last update: 2008-02-25 05:23 [from the cache] ©2003-2008 | ||||||||||