Re: Request for feedback on Generic Timeofday Subsystem (B20)

["Luck, Tony" <tony.luck@intel.com>]

On Tue, Mar 07, 2006 at 03:01:58PM -0800, john stultz wrote:
> You are right there. The jitter handling (if I recall, basically a
> cmpxchg w/ the last read cycle value to be sure the clocksource doesn't
> go backward) wouldn't be doable in userspace, but it seems that would
> already be a pretty bad hit on performance. Is it not? And how many
> systems actually use unsycned/jittery ITCs instead of alternative mmioed
> clocksources?

Yes the cmpxchg can be painful on a large NUMA ... so those systems tend
to use a non-jittery source.  Smaller machines may not have access (as
BIOS may not describe where the HPET is), and there is also a tradeoff
since reading the "ar.itc" register is much faster[1] than reading some
bus-based clock ... so the cmpxchg may not hurt too badly if you only
have a few cpus.

> Regardless, if its really a blocking issue, I'm not opposed to putting
> the direct access methods back into the structure, or going with an
> alternative solution to make these bits doable. Ingo might have a better
> idea for this as well.

I'm always open to a "better idea" ... but if one of those fails to show up
then I'd like to have the direct access methods.

> Do you have any other issues or questions?

Not at this time.

-Tony

[1] Ok, "is less slow than" (reading ar.itc isn't "fast" either).