From: Joshua Hahn Date: Thu, 9 Oct 2025 19:29:30 +0000 (-0700) Subject: mm/page_alloc: clarify batch tuning in zone_batchsize X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=5ec8eb2766533dc3f7252381a28abd4568a677ff;p=users%2Fjedix%2Flinux-maple.git mm/page_alloc: clarify batch tuning in zone_batchsize Patch series "mm/page_alloc: pcp->batch cleanups", v2. Two small cleanups for mm/page_alloc. Patch 1 cleans up a misleading comment about how pcp->batch is calculated, and folds in the calculation to increase clarity. No functional change intended. Patch 2 corrects zones from reporting that their pcp->batch is 0 when it is actually 1. Namely, corrects ZONE_DMA from reporting that its batch size is 0. This patch (of 2): Recently while working on another patch about batching free_pcppages_bulk [1], I was curious why pcp->batch was always 63 on my machine. This led me to zone_batchsize(), where I found this set of lines to determine what the batch size should be for the host: batch = min(zone_managed_pages(zone) >> 10, SZ_1M / PAGE_SIZE); batch /= 4; /* We effectively *= 4 below */ if (batch < 1) batch = 1; All of this is good, except the comment above which says "We effectively *= 4 below". Nowhere else in the function zone_batchsize(), is there a corresponding multipliation by 4. Looking into the history of this, it seems like Dave Hansen had also noticed this back in 2013 [1]. Turns out there *used* to be a corresponding *= 4, which was turned into a *= 6 later on to be used in pageset_setup_from_batch_size(), which no longer exists. Despite this mismatch not being corrected in the comments, it seems that getting rid of the /= 4 leads to a performance regression on machines with less than 250G memory and 176 processors. As such, let us preserve the functionality but clean up the comments. Fold the /= 4 into the calculation above: bitshift by 10+2=12, and instead of dividing 1MB, divide 256KB and adjust the comments accordingly. No functional change intended. Link: https://lkml.kernel.org/r/20251009192933.3756712-1-joshua.hahnjy@gmail.com Link: https://lkml.kernel.org/r/20251009192933.3756712-2-joshua.hahnjy@gmail.com Link: https://lore.kernel.org/all/20251002204636.4016712-1-joshua.hahnjy@gmail.com/ [1] Signed-off-by: Joshua Hahn Suggested-by: Dave Hansen Acked-by: Vlastimil Babka Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton --- diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 600d9e981c23..39368cdc953d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5860,13 +5860,12 @@ static int zone_batchsize(struct zone *zone) int batch; /* - * The number of pages to batch allocate is either ~0.1% - * of the zone or 1MB, whichever is smaller. The batch + * The number of pages to batch allocate is either ~0.025% + * of the zone or 256KB, whichever is smaller. The batch * size is striking a balance between allocation latency * and zone lock contention. */ - batch = min(zone_managed_pages(zone) >> 10, SZ_1M / PAGE_SIZE); - batch /= 4; /* We effectively *= 4 below */ + batch = min(zone_managed_pages(zone) >> 12, SZ_256K / PAGE_SIZE); if (batch < 1) batch = 1;