[PATCH V3 0/2] mm: page_alloc: fixes for high atomic reserve caluculations

[PATCH V3 0/2] mm: page_alloc: fixes for high atomic reserve caluculations

[Charan Teja Kalla]

The state of the system where the issue exposed shown in oom kill logs:
[  295.998653] Normal free:7728kB boost:0kB min:804kB low:1004kB
high:1204kB reserved_highatomic:8192KB active_anon:4kB inactive_anon:0kB
active_file:24kB inactive_file:24kB unevictable:1220kB writepending:0kB
present:70732kB managed:49224kB mlocked:0kB bounce:0kB free_pcp:688kB
local_pcp:492kB free_cma:0kB
[  295.998656] lowmem_reserve[]: 0 32
[  295.998659] Normal: 508*4kB (UMEH) 241*8kB (UMEH) 143*16kB (UMEH)
33*32kB (UH) 7*64kB (UH) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 7752kB

From the above, it is seen that ~16MB of memory reserved for high atomic
reserves against the expectation of 1% reserves which is fixed in the
1st patch.

Don't reserve the high atomic page blocks if 1% of zone memory size is
below a pageblock size.

Changes in V3:
 o Seperated the patch of unreserving the high atomic pageblock done from
   should reclaim retry.
 o Don't reserve high atomic page blocks for smaller zone sizes.

Changes in V2:
 o Unreserving the high atomic page blocks is done from should_reclaim_retry()
 o Reserve minimum and max memory for high atomic reserves as a pageblock and
   1% of the memory zone respectively.
 o drain the pcp lists before falling back to OOM.
 o https://lore.kernel.org/linux-mm/cover.1699104759.git.quic_charante@quicinc.com/

Changes in V1:
 o Unreserving the high atomic page blocks is tried to fix from
   the oom kill path rather than in should_reclaim_retry()
 o discussed why a lot more than 1% of managed memory is reserved
   for high atomic reserves.
 o https://lore.kernel.org/linux-mm/1698669590-3193-1-git-send-email-quic_charante@quicinc.com/

Charan Teja Kalla (2):
  mm: page_alloc: correct high atomic reserve calculations
  mm: pagealloc: enforce minimum zone size to do high atomic reserves

 mm/page_alloc.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH V3 1/2] mm: page_alloc: correct high atomic reserve calculations

[Charan Teja Kalla]

reserve_highatomic_pageblock() aims to reserve the 1% of the managed
pages of a zone, which is used for the high order atomic allocations.

It uses the below calculation to reserve:
static void reserve_highatomic_pageblock(struct page *page, ....) {

   .......
   max_managed = (zone_managed_pages(zone) / 100) + pageblock_nr_pages;

   if (zone->nr_reserved_highatomic >= max_managed)
       goto out;

   zone->nr_reserved_highatomic += pageblock_nr_pages;
   set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
   move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL);

out:
   ....
}

Since we are always appending the 1% of zone managed pages count to
pageblock_nr_pages, the minimum it is turning into 2 pageblocks as the
nr_reserved_highatomic is incremented/decremented in pageblock sizes.

Encountered a system(actually a VM running on the Linux kernel) with the
below zone configuration:
Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
reserved_highatomic:8192KB managed:49224kB

The existing calculations making it to reserve the 8MB(with pageblock
size of 4MB) i.e. 16% of the zone managed memory.  Reserving such high
amount of memory can easily exert memory pressure in the system thus may
lead into unnecessary reclaims till unreserving of high atomic reserves.

Since high atomic reserves are managed in pageblock size granules, as
MIGRATE_HIGHATOMIC is set for such pageblock, fix the calculations for
high atomic reserves as,  minimum is pageblock size , maximum is
approximately 1% of the zone managed pages.

Acked-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
---
 mm/page_alloc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 733732e..a789dfd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1884,10 +1884,11 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone)
 	unsigned long max_managed, flags;
 
 	/*
-	 * Limit the number reserved to 1 pageblock or roughly 1% of a zone.
+	 * The number reserved as: minimum is 1 pageblock, maximum is
+	 * roughly 1% of a zone.
 	 * Check is race-prone but harmless.
 	 */
-	max_managed = (zone_managed_pages(zone) / 100) + pageblock_nr_pages;
+	max_managed = ALIGN((zone_managed_pages(zone) / 100), pageblock_nr_pages);
 	if (zone->nr_reserved_highatomic >= max_managed)
 		return;
 
-- 
2.7.4

Re: [PATCH V3 1/2] mm: page_alloc: correct high atomic reserve calculations

[David Rientjes]

On Fri, 24 Nov 2023, Charan Teja Kalla wrote:

> reserve_highatomic_pageblock() aims to reserve the 1% of the managed
> pages of a zone, which is used for the high order atomic allocations.
> 
> It uses the below calculation to reserve:
> static void reserve_highatomic_pageblock(struct page *page, ....) {
> 
>    .......
>    max_managed = (zone_managed_pages(zone) / 100) + pageblock_nr_pages;
> 
>    if (zone->nr_reserved_highatomic >= max_managed)
>        goto out;
> 
>    zone->nr_reserved_highatomic += pageblock_nr_pages;
>    set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
>    move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL);
> 
> out:
>    ....
> }
> 
> Since we are always appending the 1% of zone managed pages count to
> pageblock_nr_pages, the minimum it is turning into 2 pageblocks as the
> nr_reserved_highatomic is incremented/decremented in pageblock sizes.
> 
> Encountered a system(actually a VM running on the Linux kernel) with the
> below zone configuration:
> Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
> reserved_highatomic:8192KB managed:49224kB
> 
> The existing calculations making it to reserve the 8MB(with pageblock
> size of 4MB) i.e. 16% of the zone managed memory.  Reserving such high
> amount of memory can easily exert memory pressure in the system thus may
> lead into unnecessary reclaims till unreserving of high atomic reserves.
> 
> Since high atomic reserves are managed in pageblock size granules, as
> MIGRATE_HIGHATOMIC is set for such pageblock, fix the calculations for
> high atomic reserves as,  minimum is pageblock size , maximum is
> approximately 1% of the zone managed pages.
> 
> Acked-by: Mel Gorman <mgorman@techsingularity.net>
> Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>

Acked-by: David Rientjes <rientjes@google.com>

[PATCH V3 2/2] mm: page_alloc: enforce minimum zone size to do high atomic reserves

[Charan Teja Kalla]

Highatomic reserves are set to roughly 1% of zone for maximum and a
pageblock size for minimum.  Encountered a system with the below
configuration:
Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
reserved_highatomic:8192KB managed:49224kB

On such systems, even a single pageblock makes highatomic reserves are
set to ~8% of the zone memory. This high value can easily exert pressure
on the zone.

Per discussion with Michal and Mel, it is not much useful to reserve
the memory for highatomic allocations on such small systems[1]. Since
the minimum size for high atomic reserves is always going to be a
pageblock size and if 1% of zone managed pages is going to be below
pageblock size, don't reserve memory for high atomic allocations. Thanks
Michal for this suggestion[2].

Since no memory is being reserved for high atomic allocations and if
respective allocation failures are seen, this patch can be reverted.

[1] https://lore.kernel.org/linux-mm/20231117161956.d3yjdxhhm4rhl7h2@techsingularity.net/
[2] https://lore.kernel.org/linux-mm/ZVYRJMUitykepLRy@tiehlicka/

Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
---
 mm/page_alloc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a789dfd..9f1b33e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1885,9 +1885,12 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone)
 
 	/*
 	 * The number reserved as: minimum is 1 pageblock, maximum is
-	 * roughly 1% of a zone.
+	 * roughly 1% of a zone. But if 1% of a zone falls below a
+	 * pageblock size, then don't reserve any pageblocks.
 	 * Check is race-prone but harmless.
 	 */
+	if ((zone_managed_pages(zone) / 100) < pageblock_nr_pages)
+		return;
 	max_managed = ALIGN((zone_managed_pages(zone) / 100), pageblock_nr_pages);
 	if (zone->nr_reserved_highatomic >= max_managed)
 		return;
-- 
2.7.4

Re: [PATCH V3 2/2] mm: page_alloc: enforce minimum zone size to do high atomic reserves

[David Rientjes]

On Fri, 24 Nov 2023, Charan Teja Kalla wrote:

> Highatomic reserves are set to roughly 1% of zone for maximum and a
> pageblock size for minimum.  Encountered a system with the below
> configuration:
> Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
> reserved_highatomic:8192KB managed:49224kB
> 
> On such systems, even a single pageblock makes highatomic reserves are
> set to ~8% of the zone memory. This high value can easily exert pressure
> on the zone.
> 
> Per discussion with Michal and Mel, it is not much useful to reserve
> the memory for highatomic allocations on such small systems[1]. Since
> the minimum size for high atomic reserves is always going to be a
> pageblock size and if 1% of zone managed pages is going to be below
> pageblock size, don't reserve memory for high atomic allocations. Thanks
> Michal for this suggestion[2].
> 
> Since no memory is being reserved for high atomic allocations and if
> respective allocation failures are seen, this patch can be reverted.
> 
> [1] https://lore.kernel.org/linux-mm/20231117161956.d3yjdxhhm4rhl7h2@techsingularity.net/
> [2] https://lore.kernel.org/linux-mm/ZVYRJMUitykepLRy@tiehlicka/
> 
> Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>

Acked-by: David Rientjes <rientjes@google.com>