On 3/20/23 10:12, Mike Rapoport wrote: > On Mon, Mar 20, 2023 at 09:05:57AM +0100, Vlastimil Babka wrote: >> On 3/19/23 08:22, chenjun (AM) wrote: >> > 在 2023/3/17 20:06, Vlastimil Babka 写道: >> > >> > If we ignore __GFP_ZERO passed by kzalloc， kzalloc will not work. >> > Could we just unmask __GFP_RECLAIMABLE | __GFP_RECLAIM? >> > >> > pc.flags &= ~(__GFP_RECLAIMABLE | __GFP_RECLAIM) >> > pc.flags |= __GFP_THISNODE >> >> __GFP_RECLAIMABLE would be wrong, but also ignored as new_slab() does: >> flags & (GFP_RECLAIM_MASK | GFP_CONSTRAINT_MASK) >> >> which would filter out __GFP_ZERO as well. That's not a problem as kzalloc() >> will zero out the individual allocated objects, so it doesn't matter if we >> don't zero out the whole slab page. >> >> But I wonder, if we're not past due time for a helper e.g. >> gfp_opportunistic(flags) that would turn any allocation flags to a >> GFP_NOWAIT while keeping the rest of relevant flags intact, and thus there >> would be one canonical way to do it - I'm sure there's a number of places >> with their own variants now? >> With such helper we'd just add __GFP_THISNODE to the result here as that's >> specific to this particular opportunistic allocation. > > I like the idea, but maybe gfp_no_reclaim() would be clearer? Well, that name would say how it's implemented, but not exactly as we also want to add __GFP_NOWARN. "gfp_opportunistic()" or a better name with similar meaning was meant to convey the intention of what this allocation is trying to do, and I think that's better from the API users POV?
