On Wed, Jan 11, 2023 at 04:58:02PM +0100, Michal Hocko wrote: > On Mon 09-01-23 15:16:30, Mel Gorman wrote: > > Explicit GFP_ATOMIC allocations get flagged ALLOC_HARDER which is a bit > > vague. In preparation for removing __GFP_ATOMIC, give GFP_ATOMIC and > > other non-blocking allocation requests equal access to reserve. Rename > > ALLOC_HARDER to ALLOC_NON_BLOCK to make it more clear what the flag > > means. > > GFP_NOWAIT can be also used for opportunistic allocations which can and > should fail quickly if the memory is tight and more elaborate path > should be taken (e.g. try higher order allocation first but fall back to > smaller request if the memory is fragmented). Do we really want to give > those access to memory reserves as well? Good question. Without __GFP_ATOMIC, GFP_NOWAIT only differs from GFP_ATOMIC by __GFP_HIGH but that is not enough to distinguish between a caller that cannot sleep versus one that is speculatively attempting an allocation but has other options. That changelog is misleading, it's not equal access as GFP_NOWAIT ends up with 25% of the reserves which is less than what GFP_ATOMIC gets. Because it becomes impossible to distinguish between non-blocking and atomic without __GFP_ATOMIC, there is some justification for allowing access to reserves for GFP_NOWAIT. bio for example attempts an allocation (clears __GFP_DIRECT_RECLAIM) before falling back to mempool but delays in IO can also lead to further allocation pressure. mmu gather failing GFP_WAIT slows the rate memory can be freed. NFS failing GFP_NOWAIT will have to retry IOs multiple times. The examples were picked at random but the point is that there are cases where failing GFP_NOWAIT can degrade the system, particularly delay the cleaning of pages before reclaim. A lot of the truly speculative users appear to use GFP_NOWAIT | __GFP_NOWARN so one compromise would be to avoid using reserves if __GFP_NOWARN is also specified. Something like this as a separate patch? diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7244ab522028..0a7a0ac1b46d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4860,9 +4860,11 @@ gfp_to_alloc_flags(gfp_t gfp_mask, unsigned int order) if (!(gfp_mask & __GFP_DIRECT_RECLAIM)) { /* * Not worth trying to allocate harder for __GFP_NOMEMALLOC even - * if it can't schedule. + * if it can't schedule. Similarly, a caller specifying + * __GFP_NOWARN is likely a speculative allocation with a + * graceful recovery path. */ - if (!(gfp_mask & __GFP_NOMEMALLOC)) { + if (!(gfp_mask & (__GFP_NOMEMALLOC|__GFP_NOWARN))) { alloc_flags |= ALLOC_NON_BLOCK; if (order > 0)