On Thu, 2008-09-04 at 10:53 -0700, Linus Torvalds wrote:
quoted text
> 
> On Thu, 4 Sep 2008, Alok Kataria wrote:
> >
> > Looping for a smaller timeout is really going to strain things for
> > Virtualization.
> 
> Can you check the patch I just sent out?
> 
> It loops for a _very_ short timeout, but on the other hand it should also
> absolutely immediately notice that it's getting the wrong expected values
> under virtualization, and the fast case will then fail early.

Yep tried that, the fast calibration failed in 4-5 reboots that i did
until now. Will do some more runs just to be sure.
quoted text
> 
> It then falls back on the slow case, but I don't think you can avoid that
> under virtualization.

That's fine i think the slow calibration works well for us and we can
live with the added 200msec delay while booting. 

I am assuming the patch you just sent was for 2.6.27.
And that we won't be changing the timeout's after this patch.
So, can we also apply the 2 patches that I sent yesterday on top of this
one ? the one that calibrated against pmtimer/hpet over the full loop
and the one that fixed the warning message. Both of these will affect
the slower case, which is now not the common case when running on native
hardware.

In the long run though, I think to get rid of all this complexity, we
can think of getting the frequency from the hypervisor. Lets see, i will
try making a patch maybe early next week and send it for the x86 tree.

Thanks,
Alok

quoted text
> 
> > Even on native hardware if you reduce the  timeout to less than 10ms it
> > may result in errors in the range of 2500ppm on a 2GHz systems when
> > calibrating against pmtimer/hpet, this is far worse than what NTP can
> > correct, afaik NTP can handle errors only upto 500ppm. And IMHO that is
> > the reason why we had a timeout of 50ms before (since it limits the
> > maximum theoretical error to 500ppm)
> 
> I would not mind at all having the more precise thing happen _later_,
> especially if we can do it incrementally.
> 
> One of the problems with the TSC calibration is that we need it fairly
> early (for things like usleep()), and it needs to be in the right
> ballpark. It definitely does not need to be in the parts-per-million
> range, it needs to be in the "within a few percent" range.
> 
> (To make matters worse, the TSC isn't then even used in practice for
> real-time clocks, because of variable frequency and/or halting in idle
> states. So the actual real-time clock will actually be based on HPET or
> PM_TIMER anyway most of the time).
> 
>                 Linus

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