| Message ID | c3a2a48e2cfe08176a80eaf01c110deb9e918055.1700821416.git.quic_charante@quicinc.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: page_alloc: fixes for high atomic reserve caluculations | expand |
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>
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;
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(-)