From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 9BD9E3DEFFB for ; Fri, 24 Jul 2026 08:57:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784883436; cv=none; b=tDbpZSUP10KC/dxsNl2Ob411kPTt3Iw695S31Kvoukce8h0eHmgeD4CCO67jgI8eIYPOD2g6Wf96RYb40M3CsFY22VKmkg4eZf+edeDWLIWJ28cQ/JaSwSz+HiU6j5EHGDtVpMfGKqiz17XUdBe/A+ltbIQEHiUnDmRVwN3dTGM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784883436; c=relaxed/simple; bh=06OCjoa3ninE1X8hGnLvcvPXRluLL5tvF81Bm0TwPO4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=LEbJmAdDMO6v2N4ki5pcjhak1CcGca5J8cTjOXoXf6T+lf0YCF3ew8Rp5SVrtlWXJAzVkcNJawpxBzLNXQXQLIkUP+W0f391UXLW0ZoE0JP8e7M/xShXam49w/nNopa+0vk6vC5SACEFQz0kvkRkk1fdyKCoQGNGCgmGbtlIm6g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=qlQJL/gn; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="qlQJL/gn" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784883422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PNHjK+/JGmMsSbCYCMJWygTh1XzjGhubS/Qib62Lnjk=; b=qlQJL/gn5rJBc/IMw2KZPnUQAINlqiE87xelpStFVuECZ4i9cTMPSWq5APX4caYZFxON9+ xJf3i5YRIWOVE8jwGLezx9B2+SJ/3s84S/UGV42e9Qayz2bz0jA6FmahgZfZiz6KZ/ED2y rjhOWzsUZOk9VwEDJz51ATTx1vc9YZY= Date: Fri, 24 Jul 2026 16:56:41 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Cc: cui.tao@linux.dev, 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 To: "Lorenzo Stoakes (ARM)" References: <20260724054305.516126-1-cui.tao@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Tao Cui In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/7/24 15:30, Lorenzo Stoakes (ARM) 写道: > 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. > Understood. Thanks for the review, and for the pointer to the earlier patch [0]. I should have searched for prior attempts and referenced it rather than sending this; my apologies. Withdrawing it. I've read the coding-assistants guidelines [2] and will follow them going forward. Thanks, Tao Cui > 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