On Thu, Jul 09, 2015 at 05:07:42PM +0200, Thomas Gleixner wrote: > This all or nothing protection is a real show stopper for RT, so we > try to identify what needs protection against what and then we > annotate those sections with proper scope markers, which turn into RT > friendly constructs at compile time. > > The name of the marker in question (event_lock) might not be the best > choice, but that does not invalidate the general usefulness of fine > granular protection scope markers. We certainly need to revisit the > names which we slapped on the particular bits and pieces, and discuss > with the subsystem experts the correctness of the scope markers, but > that's a completely different story. Actually, I think there was a misunderstanding. Sebastian's patch did not include any definition of event_lock, so it looked like this is a global lock defined by -rt that is simply explicit about being global, rather than a lock that specifically protects memcg event statistics. Yeah that doesn't make a lot of sense, thinking more about it. Sorry. So localizing these locks for -rt is reasonable, I can see that. That being said, does it make sense to have such locking in mainline code? Is there a concrete plan for process-context interrupt handlers in mainline? Because it'd be annoying to maintain fine-grained locking schemes with explicit lock names in a source tree where it never amounts to anything more than anonymous cli/sti or preempt toggling. Maybe I still don't understand what you were proposing for mainline and what you were proposing as the -rt solution. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>