On Thu 12-01-23 09:11:07, Michal Hocko wrote: > On Wed 11-01-23 17:05:52, Mel Gorman wrote: > > 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. > > Fair points. > > > 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? > > I cannot say I would be happy about adding more side effects to > __GFP_NOWARN. You are right that it should be used for those optimistic > allocation requests but historically all many of these subtle side effects > have kicked back at some point. Should have looked at git grep GFP_ATOMIC | __GFP_NOWARN is quite popular with more than 50 instances. -- Michal Hocko SUSE Labs
