Re: [RFC PATCH v3 0/3] sched: simplify the select_task_rq_fair()
From: Mike Galbraith
Date: Fri Feb 22 2013 - 09:31:16 EST
On Fri, 2013-02-22 at 14:06 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@xxxxxx> 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.
Ok, bad idea.
> 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.
Yeah, that might work. We have some quick kthreads, so saving ctx
distance may get close enough to scheduler cost to be good enough.
> 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?
Yeah, should be easy, but rainy day has to happen so I have time to
measure twiddle measure measure <curse> tweak.. ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/