On Tue, 2006-03-07 at 14:40 -0800, Luck, Tony wrote: > > While if its a deal breaker, I'm ok with adding those raw access info > > back into the structure, I'd first ask why ia64 must use this very > > constrained fsyscall method instead of something more flexible where it > > doesn't have to be written in asm like vsyscall/VDSO which x86-64 and > > powerpc use? > > I can't quite see how gettimeofday() can be correctly implemented > purely in userspace on a system where there is jitter in the clock source, > but I'm clueless about how vsyscall/VDSO works.
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? 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. Do you have any other issues or questions? thanks -john - 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
