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

On Fri, 5 Sep 2008, Alok Kataria wrote:
> This can happen if, in the pit_expect_msb (the one just before the
> second read_tsc), we hit an SMI/virtualization event *after* doing the
> 50 iterations of PIT read loop, this allows the pit_expect_msb to
> succeed when the SMI returns.

So theoretically, on real hardware, the minimum of 50 reads will take
100us. The 256 PTI cycles will take 214us, so in the absolute worst case,
you can have two consecutive successful cycles despite having a 228us SMI
(or other event) if it happens just in the middle.

Of course, then the actual _error_ on the TSC read will be just half that,
but since there are two TSC reads - one at the beginning and one at the
end - and if the errors of the two reads go in opposite directions, they
can add up to 228us.

So I agree - in theory you can have a fairly big error if you hit
everything just right. In practice, of course, even that *maximal* error
is actually perfectly fine for TSC calibration.

So I just don't care one whit. The fact is, fast bootup is more important
than some crazy and totally unrealistic VM situation. The 50ms thing was
already too long, the 250ms one is unbearable.

The thing is, you _can_ calibrate the thing more carefully _later_. Use a
tiemr to do two events one second apart (without slowing down the boot) if
you want to get a really good value, along with the HPET/PMTIMER
fine-tuning. That way you should actually be able to get a _really_
precise thing, because you do need a long time to get precision. But that
long time should not be in a critical path on the bootup.


 \ /
  Last update: 2008-09-06 00:37    [W:0.052 / U:3.544 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site