On Wed, Jan 11, 2023 at 04:46:13PM +0100, Michal Hocko wrote: > On Mon 09-01-23 15:16:29, Mel Gorman wrote: > > Currently __GFP_NOFAIL allocations without any other flags can access 25% > > of the reserves but these requests imply that the system cannot make forward > > progress until the allocation succeeds. Allow __GFP_NOFAIL access to 75% > > of the min reserve. > > I am not sure this is really needed. IIRC the original motivation for > allowing NOFAIL request to access access to memory reserves was > GFP_NOFS|__GFP_NOFAIL requests which do not invoke the OOM killer. > The amount of memory reserves granted was not really important. The > point was to allow to move forward. Giving more of the reserves is a > double edge sword. It can help in some cases but it can also prevent > other high priority users from fwd progress. > > I would much rahter see such a change with an example where it really > made a difference. > Fair point but based on your review for "mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves" and only allowing non-blocking allocations to access reserves if __GFP_HIGH is also specified, this patch becomes a no-op and can be dropped. If GFP_NOFAIL requests really require deeper access to reserves, it'll have to be explicitly handled in __zone_watermark_ok and __GFP_NOFAIL would be added to the ALLOC_RESERVES collection of flags. -- Mel Gorman SUSE Labs
