On Wed, 15 Jan 2025 19:19:02 +0800 "Huang, Ying" <ying.huang@xxxxxxxxxxxxxxxxx> wrote: > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > > > On Tue, 7 Jan 2025 14:47:24 +0530 Nikhil Dhama <nikhil.dhama@xxxxxxx> 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.
