Messages in this thread | | | Date | Fri, 5 Sep 2008 15:34:33 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [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.
Linus
| |