On Fri, 29 Aug 2008, Gregory Haskins wrote: > > 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 :) I answered this on IRC, but this is for the rest of those reading this thread. Userspace (vsyscalls) can only use raw_seqlock_t. And only the read version for that matter. Since the read of raw_seqlock_t is just that, a read, no writes, and no jumping to other functions on contention. The vsyscalls should never use the -rt seqlock_t. Not modifying the raws here should make us golden. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html