> Ingo Molnar wrote: >* George Spelvin <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
