On Fri, Oct 02, 2020 at 11:07:29AM +0200, Peter Zijlstra wrote: > 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. > Even a specific function with a hint that "this is for RCU only" will not prevent abuse. > > > 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? It's enabled by default by enough distros that adding too many checks is potentially painful. Granted it would be missed by most benchmarking which tend to control allocations from userspace but a lot of performance problems I see are the "death by a thousand cuts" variety. -- Mel Gorman SUSE Labs
