Re: [FIX PATCH] mm: pcp: fix pcp->free_count reduction on page allocation,

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 15 Jan 2025 19:19:02 +0800 "Huang, Ying" <ying.huang@linux.alibaba.com> wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue, 7 Jan 2025 14:47:24 +0530 Nikhil Dhama <nikhil.dhama@amd.com> wrote:
> >
> >> In current PCP auto-tuning desgin, free_count was introduced to track
> >> the consecutive page freeing with a counter, This counter is incremented
> >> by the exact amount of pages that are freed, but reduced by half on
> >> allocation. This is causing a 2-node iperf3 client to server's network
> >> bandwidth to drop by 30% if we scale number of client-server pairs from 32
> >> (where we achieved peak network bandwidth) to 64.
> >> 
> >> To fix this issue, on allocation, reduce free_count by the exact number
> >> of pages that are allocated instead of halving it.
> >
> > The present division by two appears to be somewhat randomly chosen. 
> > And as far as I can tell, this patch proposes replacing that with
> > another somewhat random adjustment.
> >
> > What's the actual design here?  What are we attempting to do and why,
> > and why is the proposed design superior to the present one?
> 
> Cc Mel for the original design.
> 
> IIUC, pcp->free_count is used to identify the consecutive, pure, large
> number of page freeing pattern.  For that pattern, larger batch will be
> used to free pages from PCP to buddy to improve the performance.  Mixed
> free/allocation pattern should not make pcp->free_count large, even if
> the number of the pages freed is much larger than that of the pages
> allocated in the long run.  So, pcp->free_count decreases rapidly for
> the page allocation.
> 
> Hi, Mel, please correct me if my understanding isn't correct.
> 

hm, no Mel.

Nikhil, please do continue to work on this - it seems that there will
be a significant benefit to retuning this.