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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250128203118.578a46182beea6a82dcd0b1d@linux-foundation.org>
Date: Tue, 28 Jan 2025 20:31:18 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Huang, Ying" <ying.huang@...ux.alibaba.com>
Cc: Nikhil Dhama <nikhil.dhama@....com>, Ying Huang
 <huang.ying.caritas@...il.com>, <linux-mm@...ck.org>,
 <linux-kernel@...r.kernel.org>, Bharata B Rao <bharata@....com>,
 Raghavendra <raghavendra.kodsarathimmappa@....com>, Mel Gorman
 <mgorman@...hsingularity.net>
Subject: Re: [FIX PATCH] mm: pcp: fix pcp->free_count reduction on page
 allocation,

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

> Andrew Morton <akpm@...ux-foundation.org> writes:
> 
> > On Tue, 7 Jan 2025 14:47:24 +0530 Nikhil Dhama <nikhil.dhama@....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.