On Mon, Feb 13, 2017 at 11:08:55AM -0800, Andy Lutomirski wrote: > On Mon, Feb 13, 2017 at 9:57 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Mon, Feb 13, 2017 at 09:01:04AM -0800, Paul E. McKenney wrote: > >> > I think I've asked this before, but why does this live in the guts of > >> > RCU? > >> > > >> > Should we lift this state tracking stuff out and make RCU and > >> > NOHZ(_FULL) users of it, or doesn't that make sense (reason)? > >> > >> The dyntick-idle stuff is pretty specific to RCU. And what precisely > >> would be helped by moving it? > > > > Maybe untangle the inter-dependencies somewhat. It just seems a wee bit > > odd to have arch TLB invalidate depend on RCU implementation details > > like this. > > This came out of a courtyard discussion at KS/LPC. The idea is that > this optimzation requires an atomic op that could be shared with RCU > and that we probably care a lot more about this optimization on > kernels with context tracking enabled, so putting it in RCU has nice > performance properties. Other than that, it doesn't make a huge > amount of sense. > > Amusingly, Darwin appears to do something similar without an atomic > op, and I have no idea why that's safe. Given that they run on ARM, I have no idea either. Maybe they don't need to be quite as bulletproof on idle-duration detection? Rumor has it that their variant of RCU uses program-counter ranges, so they wouldn't have the RCU tie-in -- just checks of program-counter ranges and interesting dependencies on the compiler. Thanx, Paul -- 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>
