On Sun, Jan 15, 2023 at 09:10:13AM +1100, NeilBrown wrote: > On Thu, 12 Jan 2023, 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. > > Isn't that a distinction without a difference? Ideally yes but it's not always clear what the consequences of failure are. > A caller than cannot sleep MUST have other options, because failure is > always possible. > The "other option" might be failure (error to user space, dropped packets > etc), but sometimes failure IS an option. > True, but it varies how gracefully it's handled and there is some cut&paste involved and other cases where the GFP_ATOMIC usage predated the existance or awareness of NOWAIT. > So the difference between ATOMIC and NOWAIT boils down to the perceived > cost of the "other options". If that cost is high, then include > __GFP_HIGH to get GFP_ATOMIC. If that cost is low, then don't include > __GFP_HIGH and get GFP_NOWAIT. > Again, ideally yes but not necessary true. It depends on how careful the caller was. The core appears to get it right in the cases I checked, I'm less sure about drivers. > I don't think there is any useful third option that is worth supporting. > That's what we'll find out over time once the series hits a released kernel. -- Mel Gorman SUSE Labs
