From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA6FC39061D for ; Fri, 24 Jul 2026 07:30:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784878262; cv=none; b=KfCBzLE1teaNdgnDnc2+kzzvNAFCX3uMvqYvLm8SVMmWRe7C3wiRxkwZOqoeNVPpH6zDBAjGZmsjWlagkpQJQSq6YB6rZcNi6BLtlAEfAcuYI4NKMYsnuG97IAXmzxGydIOfu+8hIArOuEgqlvgoBB8qcdCMxmQt1KHmo7A8NAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784878262; c=relaxed/simple; bh=t4uk9watj5ZmuwLMH339C2b/Wmw5M3F8Qrv9+ryvi4U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TVkuzpGR/Udz4k3H7yheblsedC06AystFfsv/fawjj/H2oaMjioX3Xv5MfWbpc++WJk4c9p2obyP3bO401TLy1MfJwvrMoqoD4CC/E+CFND760ydVX1PcCG8x3UipsN3M6JquNaowhhjjenXKjnpGglUqA2NszwWks+zOF0c48k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PCFHLxp6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PCFHLxp6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 461A81F000E9; Fri, 24 Jul 2026 07:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784878259; bh=vRyaonZT0RqcsE1xlqGu0bDb/oq1AhEjwIgABdlyRuk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PCFHLxp6gQQvj6vt2fQP3B2MY2tcKYGxKG/3FXWBOlaeXxCUzDajThuZL5WzcLw7a 2ClCCMRm0cImNimHpCMjM1uT8ZoJvYHGPAsp/d2yxxFO9FwNADUJf7NeoSO+E8x+hG Cj4rKiinADILDN5eOMDTd1BwTP7cAAE4/tkROz1McJ6StnJCZMUl2f0vr78s1ByTN5 NOQcx4tam9JHbn5SnuHvI6FBWJzrZlohHOZV0ZmNrhstiJH7QysxTTjaAXpmUwe/vW 4EEZkHCJehvCCsad8jhMmXOrPoO1SPog9Zs8oRa1NzZPlvE6odAtFzRVnKJERrMErC 4S6Ps0phNhxGQ== Date: Fri, 24 Jul 2026 08:30:43 +0100 From: "Lorenzo Stoakes (ARM)" To: Tao Cui Cc: Andrew Morton , linux-mm@kvack.org, Suren Baghdasaryan , Michal Hocko , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , linux-kernel@vger.kernel.org, Tao Cui Subject: Re: [PATCH] mm/vmpressure: scale the vmpressure window with machine size Message-ID: References: <20260724054305.516126-1-cui.tao@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260724054305.516126-1-cui.tao@linux.dev> No thanks. Firstly, a change like this should be RFC, especially from somebody who has not established trust in the community yet. Secondly, this is more or less identical to a previously rejected patch ([0]) so seems to be plagiarism since you don't reference that at all. Thirdly, this is the 2nd time I've seen a submission copying that patch unacknowledged (see my response to the last one at [1]). I suspect actually that you're not plagiarising here but rather sending unacknowledged LLM-generated code in violation of kernel guidelines ([2]) - since the TODO must be a pretty obvious trigger for agents generating this patch. But regardless of which it is, this patch is not welcome. Thanks, Lorenzo [0]:https://lore.kernel.org/all/20260227221555.29969-1-mcq@disroot.org/ [1]:https://lore.kernel.org/linux-mm/aljYxLusTzZkTfnH@lucifer/ [2]:https://docs.kernel.org/process/coding-assistants.html Sorry but no - this is a subtle problem that requires expertise and a strong argument in favour with data to back it not... this. On Fri, Jul 24, 2026 at 01:43:05PM +0800, Tao Cui wrote: > From: Tao Cui > > vmpressure_win -- the number of pages the reclaimer must scan before > socket pressure is re-evaluated -- has been a fixed 512 pages (2 MB) since > vmpressure was introduced. The reclaimer scans more pages on a larger > machine, so the window is reached far more often there and socket pressure > is re-armed every handful of scanned pages. The comment at the definition > has asked for the window to scale with machine size "as we do for vmstat > thresholds" for over a decade. > > Scale it the same way calculate_normal_threshold() does: logarithmically > with memory (fls of memory in 128 MB units), computed once in a > subsys_initcall once totalram_pages() is known. A machine under 128 MB > keeps the historical 512 pages; the window then grows by SWAP_CLUSTER_MAX > * 16 per doubling of memory. > > Why this matters: the scanned/reclaimed ratio that drives socket pressure "Why this matters"... oh I wonder where I've heard that kind of phrasing before... > is averaged over the window, and the window rate-limits the evaluation. > With a fixed 2 MB window the evaluation runs the same number of times > regardless of machine size, which is disproportionately many on a large > machine. Measured by cold-booting one VM at each size and running the > same cgroup-bound reclaim workload (so the page count is identical across > sizes): > > config scaled_win pages scanned 512-win evals scaled evals > 4 GB 3072 11.9 M 23267 3877 > 8 GB 3584 11.9 M 23306 3329 > 16 GB 4096 11.9 M 23281 2910 > 32 GB 4608 11.9 M 23268 2585 > 64 GB 5120 11.9 M 23281 2328 > > For the same reclaim work the fixed window evaluates ~23k times at every > machine size; the scaled window evaluates fewer times the larger the > machine -- a 6x reduction at 4 GB growing to 10x at 64 GB (and the > logarithmic growth continues: ~11x projected at 128 GB). Each evaluation > takes the per-memcg sr_lock and may write the socket_pressure seqlock, so > on larger machines with more memcgs under pressure this is real overhead > the fixed window pays needlessly. > > The default stays 512 until the initcall runs, so early-boot reclaim is > unchanged. > > Signed-off-by: Tao Cui > --- > include/linux/vmpressure.h | 2 +- > mm/vmpressure.c | 20 +++++++++++++++++--- > 2 files changed, 18 insertions(+), 4 deletions(-) > > diff --git a/include/linux/vmpressure.h b/include/linux/vmpressure.h > index b4d13457bc2a..09111f5bdc88 100644 > --- a/include/linux/vmpressure.h > +++ b/include/linux/vmpressure.h > @@ -51,7 +51,7 @@ extern struct vmpressure *memcg_to_vmpressure(struct mem_cgroup *memcg); > extern struct mem_cgroup *vmpressure_to_memcg(struct vmpressure *vmpr); > > /* Shared with the v1 vmpressure block in mm/memcontrol-v1.c. */ > -extern const unsigned long vmpressure_win; > +extern unsigned long vmpressure_win; > extern enum vmpressure_levels vmpressure_calc_level(unsigned long scanned, > unsigned long reclaimed); > > diff --git a/mm/vmpressure.c b/mm/vmpressure.c > index 9629240d77ad..4c8671273c79 100644 > --- a/mm/vmpressure.c > +++ b/mm/vmpressure.c > @@ -31,10 +31,24 @@ > * As the vmscan reclaimer logic works with chunks which are multiple of > * SWAP_CLUSTER_MAX, it makes sense to use it for the window size as well. > * > - * TODO: Make the window size depend on machine size, as we do for vmstat > - * thresholds. Currently we set it to 512 pages (2MB for 4KB pages). > + * Scale the window with machine size, the way vmstat thresholds do: on a > + * larger machine the reclaimer scans more pages, so a fixed window would > + * re-evaluate pressure every handful of pages. The scaling is logarithmic > + * (fls, like calculate_normal_threshold()), keeping the growth moderate. > + * The default is the historical 512 pages; an early initcall applies the > + * scaling once totalram_pages() is known. > */ > -const unsigned long vmpressure_win = SWAP_CLUSTER_MAX * 16; > +unsigned long vmpressure_win __read_mostly = SWAP_CLUSTER_MAX * 16; > + > +static int __init vmpressure_init_window(void) > +{ > + unsigned long mem128m; /* machine memory in 128MB units */ > + > + mem128m = totalram_pages() >> (27 - PAGE_SHIFT); > + vmpressure_win = SWAP_CLUSTER_MAX * 16 * (1 + fls(mem128m)); > + return 0; > +} > +subsys_initcall(vmpressure_init_window); > > /* > * These thresholds are used when we account memory pressure through > -- > 2.43.0 > Cheers, Lorenzo