From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5CB114A8E for ; Thu, 4 Dec 2025 09:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764839150; cv=none; b=Di3TDJkh8qaAejUZK5gmsrbMRrM5hGo8KOvP2lBdplhAxE3M6sSPmXKXL6dTi38IL2AqYgIKFofvKbJjzw4gUe54ZpiqeZXIrryD6PJYdV5D530KX/OVxon98R9V1FjwKGr906kqtPLWyWavQBeabZOw9LDQFyyzjNGV8snMes8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764839150; c=relaxed/simple; bh=t5iAXB6iULqlr7Gf0jgG+0JkEzrhvyfrALlLbL5GnoI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EUcXfWZTcG1jVRXTm5fY4J9r0wm8t/m0OnAd4AE47DmfWsgH5LDnfInCo1P+N+S+r5ayimFzPePNuV60eZG33NrKecPwtVlC+UiRaOVXwSi9raECqMg//oJV0MqVkB10wBgNMgfQazvbpru3UgEwHSqucomrrj+gecGcJdR6Sp4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AsXEiaKq; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AsXEiaKq" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-343dd5aa6e7so662024a91.0 for ; Thu, 04 Dec 2025 01:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764839148; x=1765443948; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nhr4pVUpTAxl8RbNgTq9oKqYXeRZskyCLbxB66PTaTk=; b=AsXEiaKq1yC7Y9W+j/LEGVgCPRpEk21tEoByZNSeyIRZsZvVBxHuU7o1UMT/eCEDH0 6bzSr2PTF5sDbDJRVilsyxvrD7ARzBfq7sZeZbJh3Dbip07CUYoxp5PpW6TtBjtQxvzk tRduEFEqOv3wUuJaZaCfwwWol4RFGdF41SDSQ0HbQhjpykPGsX/4EfGFhW+jka1tBjsw j0j9wZgp9DCFkTYf2qlRfEPof5TXegU4l9asNaM26j8EZ/lM1QcubBnWdKqTrNoxdBaZ IVOTNMZPamTWkTOd2F2n5nminF1xlQAtSaXFDkYWau5bwYwjS+jANfvjmXGCquBUUdPa 00PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764839148; x=1765443948; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nhr4pVUpTAxl8RbNgTq9oKqYXeRZskyCLbxB66PTaTk=; b=N5As8wroR/Xgd/siJzEci5kZGESwlrvTFFB2C1ngaXuEu5CLPIzK+RMusgwilP1wbL MN4aT2IkCDBHc3o96HO6RgVloeHNAgOxhc6VxVLbQREhNPHAvojNnBZ6tiiTiTfKRsx0 XXF63mslyI5MTZjjQ7b9IgZGKlrnXPXNYwW4KluCeLWaUlMxsgAelIXsvRF/osfYDG0b P6hSC108N5HW1A58JLFnl9WlnirBYFjAKCsyJcXOX4ycp+nKSHRYfd3hyPKiCj5lqtYc xYcQciZNge2KusN++nDZWgL6dg3UuXWz+/XWat38Xi1IF/yJEFjAcDDOJa2KEyHj3FDV ATBg== X-Forwarded-Encrypted: i=1; AJvYcCU/+Op+iVy6Ht5Qm54Qwzq8oq3zQkW02j/p4QDOT/sdHPag1BQ8aqLdlHSwIrlrBvz17qHUbdBIbDWbi3w=@vger.kernel.org X-Gm-Message-State: AOJu0YyEWXoXLmJ5zbJzpSEtxoWw7c5Uk9IzqOFZ7g2FxTfRqYo2OYIq KY65anbeYb3LD6KkQp2WM+cq3Dd54vqthLIohP9UyrEAlNZtpZCsVf0z X-Gm-Gg: ASbGncvNgBJL08jYwmFztw7vQXTl0TkvKhVusXpBsGOVglRlcO8M30S7Srz1NEKEPC1 SgPWlVFfiZA313HJ7egUIm5bGzdh7U0HiesYeilcdXADrBy7r7r+feEdSR9TIkqDdjrlWQO+V09 m2jPO8oSPRI9mBNbNXPUBNGFBODHhPzA2SA/lkCGQJd5r0Y8FqMlAn4U34ocVt9kOSzUgEx6KtA NIzAzx/RpSt5phEBfLF9qT/5QyyW58UqzXkiqU7tBqroUppDJCyR6v+huQtpFnUPTL0PXBWegOg i0rlyMD7mh5WZoF3WACRx7WVMkolZgH7CrhdXUl6hNw//2if//oLaWJNqmXNx6R9Cli2CBfaiYt 7/l7wdhdD+QfnbnpzjWMV5H3+GsRb+cMI2S1a421RR7EGIz/eqoPZMTyrl38tu1Ro01fVBWsJ X-Google-Smtp-Source: AGHT+IGfiMOtpXgZeBx9rT3HkNo2MRxiUw9kgJxBB5QkRdJyMCEJQCvjFHmL91A7LD+DWBbzFwla3g== X-Received: by 2002:a17:90b:38ce:b0:343:7714:4c9e with SMTP id 98e67ed59e1d1-349125bf02fmr5458002a91.2.1764839147906; Thu, 04 Dec 2025 01:05:47 -0800 (PST) Received: from EBJ9932692.tcent.cn ([2a12:a305:4::3086]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3494f5a874asm1154929a91.15.2025.12.04.01.05.41 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 04 Dec 2025 01:05:47 -0800 (PST) From: Lance Yang To: david@kernel.org Cc: akpm@linux-foundation.org, axelrasmussen@google.com, chenridong@huawei.com, chenridong@huaweicloud.com, hannes@cmpxchg.org, jaewon31.kim@samsung.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, lujialin4@huawei.com, mhocko@kernel.org, shakeel.butt@linux.dev, weixugc@google.com, yuanchu@google.com, yuzhao@google.com, zhengqi.arch@bytedance.com, Lance Yang Subject: Re: [PATCH -next] mm: vmscan: correct nr_requested tracing in Date: Thu, 4 Dec 2025 17:05:34 +0800 Message-ID: <20251204090534.22909-1-ioworker0@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: <98cbf348-ff21-4c90-af32-b8009c34e5fd@kernel.org> References: <98cbf348-ff21-4c90-af32-b8009c34e5fd@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Lance Yang On Wed, 3 Dec 2025 12:33:07 +0100, David Hildenbrand (Red Hat) wrote: > On 12/3/25 10:40, Chen Ridong wrote: > > From: Chen Ridong > > > > When enabling vmscan tracing, it is observed that nr_requested is always > > 4096, which is confusing. > > > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... > > > > This is because it prints MAX_LRU_BATCH, which is meaningless as it's a > > constant. To fix this, modify it to print nr_to_scan as isolate_lru_folios > > does. > > > > Fixes: 8c2214fc9a47 ("mm: multi-gen LRU: reuse some legacy trace events") > > Signed-off-by: Chen Ridong > > --- > > mm/vmscan.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index fddd168a9737..8cfafd50a7a8 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4601,7 +4601,7 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > > count_memcg_events(memcg, item, isolated); > > count_memcg_events(memcg, PGREFILL, sorted); > > __count_vm_events(PGSCAN_ANON + type, isolated); > > - trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, MAX_LRU_BATCH, > > + trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, > > scanned, skipped, isolated, > > We do that in isolate_lru_folios(). > > Given that we do > > int remaining = min(nr_to_scan, MAX_LRU_BATCH); > > and effectively cap it, I wonder if we would want to trace that capped > valued instead of MAX_LRU_BATCH. Yeah, since we explicitly clamp the work at MAX_LRU_BATCH, the trace should reflect that reality :)