lkml.org 
[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.125 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site