From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 340171BF33 for ; Fri, 3 Apr 2026 03:17:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775186227; cv=none; b=XueBxn8sogWwFlMK/vqb4IOG6VJYLIPc/89lB3JYITiz85suXOW5ZL/xT+Vr5cxre7g4IcfuwIjxvGys79ZXWq6FCSwb3VJwo19TzVPqJbKoFrkJLhgDPiZ/EqlyVi5d59VdcmFY3Chbq5IFSQ6OCZLrn1ONGNVXwnx3IhwMD0w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775186227; c=relaxed/simple; bh=SxDOEgzkNn7UwBzkqt6n3MIgS1dw6g9PJ/csXxRCPU4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A+Hiws1twXhi9AMTjNnlUkwpsf20uLAr0EOaImADawMAN3xHinn5seUuktGXY6Zc92EHhGzbseqjM771Kjlb/V5y9+IGYSRsvRgcDzSTvKu6A8MA4pGJyh41SZpGRXpcQdjPwnT8k1mVwJcKj63xUP70p4ZZ4AfDMVIswhn8nmw= 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=P562Gz4E; arc=none smtp.client-ip=209.85.215.176 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="P562Gz4E" Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-c766a95a72dso882396a12.1 for ; Thu, 02 Apr 2026 20:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775186225; x=1775791025; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dFnDoZvmaKZS9xl10TAAVVbDQeroSu+kZDSt0MQ8jME=; b=P562Gz4E59AUOXABoXktkADdgbFeneV76me14IFvUdlKc/8JzKtxCXE4QJbeg7s8f+ yoPAyu9AjtXOeEDZcA5HSkc0ALm1n8pJge408Ro9jy7X7q40oA6khx0FtSd3Vk8p20F/ xHJjUeuaN4xaXVLYAVcM4mqmb4yZw5Tm80n6hdQduw/Krg9pno+StmxUq+y96ozvYO8k GwgioKSB3+r076VzVSyslfSHAJt149ZXIJIHLkBf0tGebt6Xop8a+CtSiOyLKF1UV/AD bwj0WxK9l02uB+tVb+JV8J0u9KtppGcK6WKqgqVaSM5HMerARJXr018TvAbzRAHCJZID 9wBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775186225; x=1775791025; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dFnDoZvmaKZS9xl10TAAVVbDQeroSu+kZDSt0MQ8jME=; b=HtFqrvmSjriqX8NfWhlJC7pfLZ6wSzs24YRG7ya+rd+Mq44w2oVbxFdPyD0MFo+4n8 8+rLgTvkUHExhL3LM4D1OYRLv7QgAY3qwLM9L4cdjM47/VQcRQnqr/PvcX3PKS220S7t w7EIH5bvi2ZR6RuxvXDR5V11LqaEHEOVsRJPOUMsIgLyQSur0hB/CWxNnzjtiOUF1P8j bOu5HXY1jO6j4j270DoYMMqhbE+TV/33OyN6pjDVel32IuU2GHMyZaSDtrH4m+SS1oOJ 7U93ySyKMWZ8RIwKc5A9O/snBq21lLwGYjuvW1epRxJJTPDL5RjP4gaN7xgPkIa2DabU /Z5Q== X-Forwarded-Encrypted: i=1; AJvYcCULq+AxK/tKdqF8VPmO9TciAzPqI/KANriDodGPIczVDaoI/jXhbr+PfgXcXsRTJgJtLdxrNKUOFa0sEv8=@vger.kernel.org X-Gm-Message-State: AOJu0Yxfdpn1zB3mnkLOIgq9VNb/rJzw4oWSZEBePsemPM4+kE5xfrax rJ6kjmfKgHQktHbKFw8ujQVAVGn4XarX3/YtD6mURFsLppAUa8qfLUjU X-Gm-Gg: ATEYQzxIxIgo5p5/C0FTmVVnapzjUhEnR6OBeTRDUwb4JVDfjnbbn/4pyZ09t1g7w+R aVXsy2JfKsk+xYfsImJ0g1Mu6GlZFUBssLO5670aCYxlQPdvc8GG0NrmZrZkG+TC9yfRaFmJ0SY O7ac/E7ZFYOmP3TA/Jx9Dg7oztli/zbI9suns7Qf//iDC3aBCuD4cR6wvDO6VR85qmWaMYXxH6O HAPhINg1Rf+grRBqzUSlx84807fm7cMMZBq+T0DxWH+0ugom2zsaT86qOO3h4y+VgwDwcxvF7IL g/6dFwvaiWoLttOkBlRKl47MUHE0CeJhCBvGXNpx8qtNl/eLdEggqUJszHjarG6auQGTTCagmQ4 L0fpfMMcYsDA+MgStg3GrW+dPRKLPWyPwdxBe2aWb9Z3Hz00sSmoItmJGuFwxriz///W+hKTgIK Ev94/2yRO3fErHF9qdi0xulIolmzuUqzlDLO5lbCpmizQ1Ev0XNtvjMe/+Iew8AVDIN0JYnfCC5 OqAYok= X-Received: by 2002:a05:6a20:7d8a:b0:398:8f2a:5dd4 with SMTP id adf61e73a8af0-39f2ed97df6mr1324370637.8.1775186225496; Thu, 02 Apr 2026 20:17:05 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.21]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82cf9c3d67dsm5237029b3a.33.2026.04.02.20.16.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 20:17:04 -0700 (PDT) Date: Fri, 3 Apr 2026 11:16:57 +0800 From: Kairui Song To: linux-mm@kvack.org Cc: Kairui Song , Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org, Qi Zheng , Baolin Wang Subject: Re: [PATCH v3 01/14] mm/mglru: consolidate common code for retrieving evictable size Message-ID: References: <20260403-mglru-reclaim-v3-0-a285efd6ff91@tencent.com> <20260403-mglru-reclaim-v3-1-a285efd6ff91@tencent.com> 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: <20260403-mglru-reclaim-v3-1-a285efd6ff91@tencent.com> Forwarding sashiko review in case anyone has concern about it: https://sashiko.dev/#/patchset/20260403-mglru-reclaim-v3-0-a285efd6ff91%40tencent.com?part=1 > commit e0119c3e147f68096f59fb96e1e69e83ecdfce40 > Author: Kairui Song > mm/mglru: consolidate common code for retrieving evictable size > This commit merges commonly used code for counting evictable folios in a > lruvec into a new helper function lruvec_evictable_size. > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 5a8c8fcccbfc9..adc07501a1375 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > [ ... ] > > @@ -4909,9 +4915,6 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > > static bool should_run_aging(struct lruvec *lruvec, unsigned long max_seq, > > int swappiness, unsigned long *nr_to_scan) > > { > > - int gen, type, zone; > > - unsigned long size = 0; > > - struct lru_gen_folio *lrugen = &lruvec->lrugen; > > DEFINE_MIN_SEQ(lruvec); > > > > *nr_to_scan = 0; > > @@ -4919,18 +4922,7 @@ static bool should_run_aging(struct lruvec *lruvec, unsigned long max_seq, > > if (evictable_min_seq(min_seq, swappiness) + MIN_NR_GENS > max_seq) > > return true; > > > > - for_each_evictable_type(type, swappiness) { > > - unsigned long seq; > > - > > - for (seq = min_seq[type]; seq <= max_seq; seq++) { > > - gen = lru_gen_from_seq(seq); > > - > > - for (zone = 0; zone < MAX_NR_ZONES; zone++) > > - size += max(READ_ONCE(lrugen->nr_pages[gen][type][zone]), 0L); > > - } > > - } > > - > > - *nr_to_scan = size; > > + *nr_to_scan = lruvec_evictable_size(lruvec, swappiness); > The commit message notes there is no behavior change, but does delegating > to lruvec_evictable_size() introduce a subtle state inconsistency? > Previously, should_run_aging() evaluated the aging conditions and iterated > the generations to calculate the evictable size using a single snapshot of > max_seq (passed as an argument) and min_seq (read locally via > DEFINE_MIN_SEQ). > The new lruvec_evictable_size() helper re-reads both sequence numbers > internally via its own DEFINE_MAX_SEQ and DEFINE_MIN_SEQ macros. If the > sequence numbers advance concurrently, the calculated size might be based > on a different snapshot than the one used just lines above to determine if > aging should run. > Could this lead to unintended behavioral changes during concurrent > execution? This is totally fine. Right lruvec_evictable_size re-reads max_seq - and that's really trivial, I don't think anyone will observe any different in any way. The time windows is so tiny and even if a different value is read, the updated value is more accurate for getting the LRU size.