On Sat, 20 Nov 2021, Matthew Wilcox wrote: > On Fri, Nov 19, 2021 at 10:14:38AM +1100, NeilBrown wrote: > > On Thu, 18 Nov 2021, Matthew Wilcox wrote: > > > Surely this should be gfpflags_allow_blocking() instead of poking about > > > in the innards of gfp flags? > > > > Possibly. Didn't know about gfpflags_allow_blocking(). From a quick > > grep in the kernel, a whole lot of other people don't know about it > > either, though clearly some do. > > > > Maybe we should reaname "__GFP_DIRECT_RECLAIM" to > > "__GFP_ALLOW_BLOCKING", because that is what most users seems to care > > about. > > I tend towards the school of thought that the __GFP flags should make > sense to the implementation and users should use either GFP_ or functions. > When we see users adding or subtracting __GFP flags, that's a problem. Except __GFP_NOWARN of course, or __GFP_ZERO, or __GFP_NOFAIL. What about __GFP_HIGHMEM? __GFP_DMA? __GFP_HIGH? They all seem to be quite meaningful to the caller - explicitly specifying properties of the memory or properties of the service. (But maybe you would prefer __GFP_HIGH be spelled "__GFP_LOW_WATERMARK" so it would make more sense to the implementation). __GFP_DIRECTRECLAIM seems to me to be more the exception than the rule - specifying internal implementation details. Actually ... I take it back about __GFP_NOWARN. That probably shouldn't exist at all. Warnings should be based on how stressed the mm system is, not on whether the caller wants thinks failure is manageable. NeilBrown
