On Fri, Oct 02, 2020 at 09:50:14AM +0100, Mel Gorman wrote: > On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote: > > > +#define ___GFP_NO_LOCKS 0x800000u > > > > Even if a new gfp flag gains a sufficient traction and support I am > > _strongly_ opposed against consuming another flag for that. Bit space is > > limited. > > That is definitely true. I'm not happy with the GFP flag at all, the > comment is at best a damage limiting move. It still would be better for > a memory pool to be reserved and sized for critical allocations. This is one of the reasons I did a separate allocation function. No GFP flag to leak into general usage. > > Besides that we certainly do not want to allow craziness like > > __GFP_NO_LOCK | __GFP_RECLAIM (and similar), do we? > > That would deserve to be taken to a dumpster and set on fire. The flag > combination could be checked in the allocator but the allocator path fast > paths are bad enough already. Isn't that what we have CONFIG_DEBUG_VM for?
