lkml.org 
[lkml]   [2008]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC patch 0/4] TSC calibration improvements

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

> On Thu, 4 Sep 2008, Ingo Molnar wrote:
> >
> > hm, unless i'm missing something i think here we still have a small
> > window for an SMI or some virtualization delay to slip in and cause
> > massive inaccuracy: if the delay happens _after_ the last
> > pit_expect_msb() and _before_ the external get_cycles() call. Right?
>
> Yes. I had the extra pit_expect_msb() originally, but decided that
> basically a single-instruction race for somethign that ran without any
> MSI for 15ms was a bit pointless.

the race is wider than that i think: all it takes an SMI at the last PIO
access, so the window should be 1 usec, against a 15000 usecs period.
That's 1 out of 15,000 boxes coming up with totally incorrect
calibration.

we also might have a very theoretical race of an SMI taking exactly 65
msecs so that the whole PIT wraps around and fools the fastpath - the
chance for that would be around 1:300 - assuming we only have to hit the
right MSB with a ~200 usecs precision). That assumes equal distribution
of SMI costs which they certainly dont have - most of them are much less
than 60 msecs. So i dont think it's an issue in practice - on real hw.

But it's still a possibility unless i'm missing something. We could
protect against that case by reading the IRQ0-pending bit and making
sure it's not pending after we have done the closing TSC readout.

> But adding another pit_expect_msb() is certainly not wrong.

ok, i kept that bit.

Ingo


\
 
 \ /
  Last update: 2008-09-04 23:37    [W:0.100 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site