Messages in this thread | | | Date | Wed, 15 Sep 2004 00:28:49 +1000 | From | Nick Piggin <> | Subject | Re: [patch] sched: fix scheduling latencies for !PREEMPT kernels |
| |
Andrea Arcangeli wrote: > On Tue, Sep 14, 2004 at 11:33:48PM +1000, Nick Piggin wrote: > >>cond_rescheds everywhere? Isn't this now the worst of both worlds? > > > 1) cond_resched should become a noop if CONFIG_PREEMPT=y > (cond_resched_lock of course should still unlock/relock if > need_resched() is set, but not __cond_resched).
Unfortunately we need to keep the cond_rescheds that are called under the bkl. Otherwise yes, this would be nice to be able to do.
> 2) all Ingo's new and old might_sleep should be converted to > cond_resched (or optionally to cond_resched_costly, see point 5). > 3) might_sleep should return a debug statement. > 4) cond_resched should call might_sleep if need_resched is not set if > CONFIG_PREEMPT=n is disabled, and it should _only_ call might_sleep > if CONFIG_PREEMPT=y after we implement point 1. > 5) no further config option should exist (if we really add an option > it should be called CONFIG_COND_RESCHED_COSTLY of similar to > differentiate scheduling points in fast paths (like spinlock places > with CONFIG_PREEMPT=n) (so you can choose between cond_resched() and > cond_resched_costly()) > > I recommended point 2,3,4,5 already (a few of them twice), point 1 (your > point) looks lower prio (CONFIG_PREEMPT=y already does an overkill of > implicit need_resched() checks anyways). >
Which is why we don't need more of them ;)
> >>Why would someone who really cares about latency not enable preempt? > > > to avoid lots of worthless cond_resched in all spin_unlock and to avoid > kernel crashes if some driver is not preempt complaint? >
Well I don't know how good an argument the crashes one is these days, but generally (as far as I know) those who really care about latency shouldn't mind about some extra overheads.
Now I don't disagree with some cond_rescheds for places where !PREEMPT latency would otherwise be massive, but cases like doing cond_resched for every page in the scanner is something that you could say is imposing overhead on people who *don't* want it (ie !PREEMPT).
> I've a better question for you, why would someone ever disable > CONFIG_PREEMPT_VOLUNTARY? That config option is a nosense as far as I > can tell. If something it should be renamed to > "CONFIG_I_DON_T_WANT_TO_RUN_THE_OLD_KERNEL_CODE" ;) >
:) I don't think Ingo intended this for merging as is. Maybe it is to test how much progress he has made. - 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/
| |