Messages in this thread | | | Date | Thu, 31 Mar 2011 12:46:01 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC 2/2] Make x86 calibrate_delay run in parallel. |
| |
* Avi Kivity <avi@redhat.com> wrote:
> On 03/31/2011 11:57 AM, Ingo Molnar wrote: > >> > >> I am not trying to be argumentative. I never got an understanding of > >> what was going wrong with that earlier patch and am hoping for some > >> understanding now. > > > > Well, if calibrate_delay() calls run in parallel then different > > hyperthreads will impact each other. > > It's different but not more wrong. If delay() later runs on a thread whose > sibling is busy, it will in fact give more accurate results.
No, it's actively wrong: because it makes the delay loop *run faster* when other siblings
I.e. this shortens udelay(X)s potentially, which is far more dangerous than the current conservative approach of potentially *lengthening* them.
> > Really, there's no good reason why every CPU should be calibrated on a > > system running identical CPUs, right? Mixed-frequency systems are rather > > elusive on x86. > > Good point. And udelay() users are probably not sensitive to accuracy anyway > (which changes with load and thermal conditions).
True with one important distinction: they are only sensitive to one fact, that the delay should not be *shorter* than specified. By shortening udelay() we essentially overclock the hardware's tolerances - not good.
Thanks,
Ingo
| |