Message-ID: <20090317161322.GA25904@elte.hu>
Date:	Tue, 17 Mar 2009 17:13:22 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jesper Krogh <jesper@...gh.cc>,
	john stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 17 Mar 2009, Ingo Molnar wrote:
> > 
> > Cool. Will you apply it yourself (in the merge window) or should 
> > we pick it up?
> 
> I'll commit it.  I already split it into two commits - one for the 
> trivial startup problem that John had, one for the "estimate error 
> and exit when smaller than 500ppm" part.

ok.

> > Incidentally, yesterday i wrote a PIT auto-calibration routine 
> > (see WIP patch below).
> > 
> > The core idea is to use _all_ thousands of measurement points 
> > (not just two) to calculate the frequency ratio, with a built-in 
> > noise detector which drops out of the loop if the observed noise 
> > goes below ~10 ppm.
> 
> I suspect that reaching 10 ppm is going to take too long in 
> general. Considering that I found a machine where reaching 500ppm 
> took 16ms, getting to 10ppm would take almost a second. That's a 
> long time at bootup, considering that people want the whole boot 
> to take about that time ;)
> 
> I also do think it's a bit unnecessarily complicated. We really 
> only care about the end points - obviously we can end up being 
> unlucky and get a very noisy end-point due to something like SMI 
> or virtualization, but if that happens, we're really just better 
> off failing quickly instead, and we'll go on to the slower 
> calibration routines.

That's the idea of my patch: to use not two endpoints but thousands 
of measurement points. That way we dont have to worry about the 
precision of the endpoints - any 'bad' measurement will be 
counter-acted by thousands of 'good' measurements.

That's the theory at least - practice got in my way ;-)

By measuring more we can get a more precise result, and we also do 
not assume anything about how much time passes between two 
measurement points. A single measurement is:

+	/*
+        * We use the PIO accesses as natural TSC serialization barriers:
+        */
+       pit_lsb                 = inb(0x42);
+       tsc                     = get_cycles();
+       pit_msb                 = inb(0x42);

Just like we can prove that there's an exoplanet around a star, just 
by doing a _ton_ of measurements of a very noisy data source. As 
long as there's an underlying physical value to be measured (and we 
are not measuring pure noise) that value is recoverable, with enough 
measurements.

> On real hardware without SMI or virtualization overhead, the 
> delays _should_ be very stable. On my main machine, for example, 
> the PIT read really seems very stable at about 2.5us (which 
> matches the expectation that one 'inb' should take roughly one 
> microsecond pretty closely). So that should be the default case, 
> and the case that the fast calibration is designed for.
> 
> For the other cases, we really can just exit and do something 
> else.
> 
> > It's WIP because it's not working yet (or at all?): i couldnt 
> > get the statistical model right - it's too noisy at 1000-2000 
> > ppm and the frequency result is off by 5000 ppm.
> 
> I suspect your measurement overhead is getting noticeable. You do 
> all those divides, but even more so, you do all those traces. 
> Also, it looks like you do purely local pairwise analysis at 
> subsequent PIT modelling points, which can't work - you need to 
> average over a long time to stabilize it.

Actually, it's key to my trick that what happens _between_ the 
measurement points does not matter _at all_.

My 'delta' algorithm does not assume anything about how much time 
passes between two measurement points - it calculates the slope and 
keeps a rolling average of that slope.

That's why i could put the delta analysis there. We are capturing 
thousands of measurement points, and what matters is the precision 
of the 'pair' of (PIT,TSC) timestamp measurements.

I got roughly the same end result noise and the same anomalies with 
tracing enabled and disabled. (and the number of data points was cut 
in half with tracing enabled)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists