On Thu, 9 Jul 2015, Johannes Weiner wrote: > 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? They exist today. Though they are opt-in while on rt we enforce them. > 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. For the time being it's RT only, but as we are trying to come up with a way to merge RT into mainline, we start to figure out how to break that per cpu BKL style protection into understandable bits and pieces. We are still debating how that final annotation mechanism will look like, but something like the local lock mechanism might come out of it. That said, even w/o RT it makes a lot of sense to document explicitely in the code WHICH resource needs to be protected against WHAT. In that very case, you do not care about interrupt handlers per se, you only care about interrupt handlers which might recurse into that code, right? So the protection scope annotation should be able to express that independent of the underlying implementation details. protect_irq_concurrency(protected_resource) fiddle_with_resource() unprotect_irq_concurrency(protected_resource) Gives a very clear picture, about what you care and what needs to be protected. The ideal outcome of such annotations would be, that tools (runtime or static analysis) are able to find violations of this. i.e. if some other place just fiddles with resource w/o having the protection scope annotation in place, then tools can yell at you, like we do today with lockdep and other mechanisms. Thanks, tglx -- 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>