Messages in this thread | | | Date | Thu, 12 Jan 2023 09:43:41 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 5/7] mm/page_alloc.c: Allow __GFP_NOFAIL requests deeper access to reserves |
| |
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
| |