Re: [git pull] scheduler fixes

Ingo Molnar
2008-05-13T14:42:52Z

* Matthew Wilcox <matthew@wil.cx> wrote:

> > a 50% AIM7 slowdown maybe? With the BKL being a spinlock again it
> > doesnt matter much in practice though.
>
> You're not understanding me. This is completely inapplicable to the
> BKL because only one task can be in wakeup at a time (due to it having
> a maximum value of 1). There's no way to hit this race with the BKL.
> The only kind of semaphore that can hit this race is the kind that can
> have more than one wakeup in progress at a time -- ie one which can
> have a value >1. Like completions and real counting semaphores.

yes, but even for parallel wakeups for completions it's good in general
to keep more tasks in flight than to keep less tasks in flight.

Perhaps the code could throttle them to nr_cpus, but otherwise, as the
BKL example has shown it (in another context), we do much better if we
overload the scheduler (in which case it can and does batch
intelligently) than if we try to second-guess it and under-load it and
create lots of scheduling events.

i'd agree with you that are no numbers available pro or contra, so you
are right that my 50% point does not apply to your argument.

> So the only thing worth talking about (and indeed, it's now entirely
> moot) is what's the best way to solve this problem /for this kind of
> semaphore/.

it's not really moot in terms of improving the completions code i
suspect? For XFS i guess performance matters.

Ingo