On Wed, Aug 12, 2020 at 10:32:50AM +0200, Thomas Gleixner wrote: > Paul, > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> writes: > > On Wed, Aug 12, 2020 at 02:13:25AM +0200, Thomas Gleixner wrote: > >> That much I understood, but I somehow failed to figure the why out > >> despite the elaborate changelog. 2 weeks of 30+C seem to have cooked my > >> brain :) > > > > Ouch!!! And what on earth is Germany doing being that warm??? > > The hot air exhaustion of politicians, managers and conspiracy > mythomaniacs seens to have contributed extensivly to global warming > lately. In that case, our only hope here in this geography is that we are in a simulation, so that the hot air will cause a signed integer overflow to negative numbers some fraction of the time. :-( > >> But what makes me really unhappy is that my defense line against > >> allocations from truly atomic contexts (from RT POV) which was enforced > >> on RT gets a real big gap shot into it. > > > > Understood, and agreed: We do need to keep the RT degradation in > > check. > > Not only that. It's bad practice in general to do memory allocations > from such contexts if not absolutely necessary and the majority of cases > which we cleaned up over time were just from the "works for me and why > should I care and start to think" departement. Agreed, and I continue to see some of that myself. :-/ > >> I can understand your rationale and what you are trying to solve. So, if > >> we can actually have a distinct GFP variant: > >> > >> GFP_I_ABSOLUTELY_HAVE_TO_DO_THAT_AND_I_KNOW_IT_CAN_FAIL_EARLY > >> > >> which is easy to grep for then having the page allocator go down to the > >> point where zone lock gets involved is not the end of the world for > >> RT in theory - unless that damned reality tells otherwise. :) > > > > I have no objection to an otherwise objectionable name in this particular > > case. After all, we now have 100 characters per line, right? ;-) > > Hehe. I can live with the proposed NO_LOCK name or anything distinct > which the mm people can agree on. Sounds good. ;-) > >> To make it consistent the same GFP_ variant should allow the slab > >> allocator go to the point where the slab cache is exhausted. > > > > Why not wait until someone has an extremely good reason for needing > > this functionality from the slab allocators? After all, leaving out > > the slab allocators would provide a more robust defense line. Yes, > > consistent APIs are very good things as a general rule, but maybe this > > situation is one of the exceptions to that rule. > > Fair enough. > > >> Having a distinct and clearly defined GFP_ variant is really key to > >> chase down offenders and to make reviewers double check upfront why this > >> is absolutely required. > > > > Checks for that GFP_ variant could be added to automation, though reality > > might eventually prove that to be a mixed blessing. > > Did you really have to remind me and destroy my illusions before I was > able to marvel at them? Apologies! I am afraid that it has become a reflex due to living in this time and place. My further fear is that I will have all to great an opportunity for further reinforcing this reflex in the future. :-/ Thanx, Paul
