* Mike Galbraith <[email protected]> wrote:
> > > No, that's too high, you loose too much of the pretty
> > > face. [...]
> >
> > Then a logical proportion of it - such as half of it?
>
> Hm. Better would maybe be a quick boot time benchmark, and
> use some multiple of your cross core pipe ping-pong time?
> That we know is a complete waste of cycles, because almost all
> cycles are scheduler cycles with no other work to be done,
> making firing up another scheduler rather pointless. If we're
> approaching that rate, we're approaching bad idea.
Well, one problem with such dynamic boot time measurements is
that it introduces a certain amount of uncertainty that persists
for the whole lifetime of the booted up box - and it also sucks
in any sort of non-deterministic execution environment, such as
virtualized systems.
I think it might be better to measure the scheduling rate all
the time, and save the _shortest_ cross-cpu-wakeup and
same-cpu-wakeup latencies (since bootup) as a reference number.
We might be able to pull this off pretty cheaply as the
scheduler clock is running all the time and we have all the
timestamps needed.
Pretty quickly after bootup this 'shortest latency' would settle
down to a very system specific (and pretty accurate) value.
[ One downside would be an increased sensitivity to the accuracy
and monotonicity of the scheduler clock - but that's something
we want to improve on anyway - and 'worst case' we get too
short latencies and we are where we are today. So it can only
improve the situation IMO. ]
Would you be interested in trying to hack on an auto-tuning
feature like this?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
