On Fri, 2013-02-22 at 14:06 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> 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.. ;-) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
