| Message ID | 20230109151631.24923-6-mgorman@techsingularity.net (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Discard __GFP_ATOMIC | expand |
On 1/9/23 16:16, 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. > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Vlastimil Babka <vbabka@suse.cz> > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6f41b84a97ac..d2df78f5baa2 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5308,7 +5308,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > * could deplete whole memory reserves which would just make > * the situation worse > */ > - page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_HARDER, ac); > + page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_MIN_RESERVE|ALLOC_HARDER, ac); > if (page) > goto got_pg; >
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. > Signed-off-by: Mel Gorman <mgorman@techsingularity.net> > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6f41b84a97ac..d2df78f5baa2 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5308,7 +5308,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > * could deplete whole memory reserves which would just make > * the situation worse > */ > - page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_HARDER, ac); > + page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_MIN_RESERVE|ALLOC_HARDER, ac); > if (page) > goto got_pg; > > -- > 2.35.3
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.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6f41b84a97ac..d2df78f5baa2 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5308,7 +5308,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, * could deplete whole memory reserves which would just make * the situation worse */ - page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_HARDER, ac); + page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_MIN_RESERVE|ALLOC_HARDER, ac); if (page) goto got_pg;
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. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)