Steven Rostedt wrote: > On Fri, 29 Aug 2008, Gregory Haskins wrote: > > >> Andi Kleen wrote: >> >>>> Im running it on a x86_64 box as we speak. How can I tell if there is a >>>> certain mode that is permitting this? >>>> >>>> >>> If the boot up says you're running with PMtimer then it uses the fallback >>> (usually happens on pre Fam10h AMD boxes). A typical Intel box >>> would use the faster ring 3 only TSC path and then explode with your >>> change I bet. >>> >>> Or step with gdb through gettimeofday() and see if it does a syscall. >>> >>> -Andi >>> >>> >> It seems to be running fine with no indication it has fallen back. >> Perhaps I need a certain workload to bring out the issue? >> > > Perhaps you never hit the slow path in userland. That's the only place it > would write. Perhaps add a dummy static variable in the fast path, and > write to it. See if that crashes you apps. > > -- Steve > Yeah, ideas crossed in the mail ;) I could just force all of the seqbegins to hit the slowpath by hacking the code and see what happens (aside from slowing down, of course ;) Question: Which seqlock_t does userspace use? I assume it uses seqlock_t and not raw_seqlock_t. But the only reason that I ask is that I converted raw_seqlock_t to use the new style as well to be consistent, even though it is not strictly necessary for the same reasons. So if perchance userspace uses the raw variant, I could solve this issue by only re-working the seqlock_t variant. Kind of a long shot, but figured I would mention it :) -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
