* George Spelvin <li...@horizon.com> wrote:
> > Ingo Molnar wrote:
> >* George Spelvin <li...@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!
No apologies needed: I should really have posted my code, but the boot
dependencies hackery I had to perform was way too embarrasing to post ...
> > 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?
it's delta/loops. So the 200K line:
[ 0.000000] tsc: RTC edge 69 from 0 to 64, at 29700569301, delta:
2700528, jitter: 2454456, loops: 13, 207732 cycles/loop
had a very big 'delta' outlier, ~1.3 msecs when we did not manage to detect any
RTC edge.
I'll run your code as well, to make sure it's not something bad in my code.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
