Messages in this thread | | | Date | 5 Jun 2015 04:24:53 -0400 | From | "George Spelvin" <> | Subject | Re: [PATCH RFC] x86, tsc: Allow for high latency in quick_pit_calibrate() |
| |
> Ingo Molnar wrote: >* George Spelvin <linux@horizon.com> wrote: >> Did you use rtc_cmos_read()? [...]
> Yeah, so initially I did, but then after I noticed the overhead I introduced: > which compiles to a single INB instruction. > > This didn't change the delay/cost behavior. > > The numbers I cited, with tens of thousands of cycles per iteration, > were from such an optimized poll loop already.
Apologies for doubting you!
>> /* This is skanky stuff that requries rewritten RTC locking to do properly */
> [ Note that no RTC locking is needed so early during bootup: this is > the boot CPU only, with only a single task running, guaranteed. ]
Yes, I guessed I could get away with it, but I hadn't traced the code far enough to be sure. But obviously I should either completely omit the locking, or do it right. Half-assed is all-wrong.
> note the 'loops' column. When it's around 117, then the read cost corresponds > roughly to the cheap-ish INB cost you have measured: 4188 cycles/loop. > > But note the frequent 30-40k cycles/loop outliers. They dominate the measurement > so filtering might not help.
I don't quite understand hoe the numbers are derived. Why does 200K cycles/loop give 13 loops, while 35K cycles/loop gives 7? Is cycles/loop a maximum?
> And this is on a 'boring' 10 years old PC (Nvidia CK804 southbridge), with no HPET > and nothing particularly fancy that I'm aware of. I tried this system first > because I expected it to work and expected problems (with RTCs being emulated via > the HPET) on more modern systems. > > If the RTC polling method is not reliable here, it might be doubly problematic on > other systems.
This is definitely an "if it ain't broke, don't fix it" area. Trying things is interesting; actually changing the kernel is not to be undertaken lightly.
| |