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). - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
