From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (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 86CCD280335 for ; Fri, 3 Apr 2026 05:01:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775192463; cv=none; b=MNX2s9RQfjpko5qMbEP85KTmVSonrQgGVpr5xDco3nHpbXeGE4ahz+HsS3Z5W3TZQky9Joc9mMKCu8wUh0w9a26Nw1rjrG29qG3uapQ7ZTqWtik4d0BGY71wdFtDTGhTdMkHiZWFfoqm3eC5NI1mCzzDZZM92gfrDyX9iq7o3vg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775192463; c=relaxed/simple; bh=xRgcWTDxcyeqJOj6fg20+QNo68lCvfClWDsWf0I5YQQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kxe2mp6+fiK+KOVKXFmrROdDtnGue3rVG61+rGNc0tbP1lqV2K+9TDnw6G8+XjLVXcCYkMPDAVVTiRP2x6YchqrEuJezf/F0pAv5gsDXprziv2JXrmURzk6QYzTNFV1JbE6dUDClRtSYM352W0DiMrn59FzhsQYdXcjW9DUqQ3A= 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=oNjEU7Dz; arc=none smtp.client-ip=209.85.216.46 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="oNjEU7Dz" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-35c1a131946so1603187a91.0 for ; Thu, 02 Apr 2026 22:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775192462; x=1775797262; 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=RQJtFaNwbncbMp+SaMn+f9Z1Y6W2kUOXpEOhhAKm3G8=; b=oNjEU7DzlLz1rYik+p6GThxlcQQ1vbHCMY+VufBq5Hs+GbkZ/YXp2uQ01lQ5k2winD BDBMjjoOMcjw8gmPhhUE7ujsN4f2fVeCKfpvZytaj6tL8X6EWRTbIvvqDrpukzeWnNXQ 1UsFEBQDX6rl+jHVjldM5DJv+CF1Tw5c/eIA9FsLpVqHRXydR+Z21zoWapnvNgpMBWQx MPcHcGXUpO28cJmChk3tIUSpAn1rWPoETDdYmKLcbWBOoPGD5EWgFDhWU/JNw2MNY1eK m55FoSrMTzDU37gyKfy70DgcQhDnh3XQmJ6cl0rMlCIcNotUtLsjcRsaz0obKCso+FGI 6UMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775192462; x=1775797262; 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=RQJtFaNwbncbMp+SaMn+f9Z1Y6W2kUOXpEOhhAKm3G8=; b=KRATd7GjKamYDBlQU2NAIfVci6cdbsGWzxx6Kp7VQnENHe0F6DS2B4iWNwgCYsPvm/ DXe9AIcwyvHq650jlfA577S9LCE2IRzrXtIOoeQszRCz3CMxYCbkDeIlsd/+L4m/q3Qr RufP21C6O82X5EC0/+3lzE71obyuZqOjMz1DnOabnUj77IBKvNRU3Dlgy/1vwenNNq9p 1km6nR2isTRtIVAX2BqADRCiA8+VtnBMiEkHaiQjJhhiJ3vyipZlyDWnUEFlfwYvfBEM 3A5KTqKNcchzu93h9a39UFZ6FTcKMPJ9wZgapuBBHSCdbfdq1wK28ylTql5i/YzJSjF9 42Zw== X-Forwarded-Encrypted: i=1; AJvYcCWfhrMfJgcfGmJDskEDmR9jDw8sH5sosyevqlObpDl7QaKhbuzHjU2L75Rhg9WkU3HyZ2NsB+6sne7JEK0=@vger.kernel.org X-Gm-Message-State: AOJu0YyL6ZHrCXTvO4JknljuN+VFK14tVd9vlipAWs5dEOu9gQKuwUrD i4Kqc4szdpRwhqi5wRz+5AadxEbL5ixHku+NB/su4oCDgK2acQr4gLji X-Gm-Gg: AeBDieurEhJ+D7wi+1TPVqOcB2Id8rw6NhS2+NbCXvGDm3DpwAT+AdUwYv2s1zROi+M dT9HRTCYzkGF2COPMl1xXPb5GLy6rcv99xeX0LzDwn/9s08C3vRgZoO1kEtiW/WV0epW41n/JH4 tqgA+YkQFwsKlbzjXnm5jhD6NSBiyfj8rD3OwoiqNj2keHG9YtF2lOmHbl8VpS5bGUrjkfNkqhq hY1D3R9fR1Q7y0jAnU8r32UMblEADu2PS3NCYuZQTY4hZnBX05lZyiHY7Twkk2KXN1FcgT6JZLS fax+/lgk0lLHb10PNdn76YQ0sxZttE8DLJu12ADb+q+XVEsf7DAow03UiNPB2Dc0l64EnHtt3J2 JONfse2gyTLJ8DiG1yqPcx0J2OC69MuASaNn24Z2/0kd1ye/qsxHgnbX+6WWd2duL0mqe939gd4 ppJ6c+WzcsszLIjbQmO7YejXY4SwYRtYdnLUdI1XkAMmZ1/nt5uFKrZSqBlPyQWCQRMKfx X-Received: by 2002:a17:90b:314b:b0:35a:2ed:9b6f with SMTP id 98e67ed59e1d1-35dd65b05e0mr4834473a91.0.1775192461715; Thu, 02 Apr 2026 22:01:01 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.21]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c76c647792bsm4474251a12.6.2026.04.02.22.00.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 22:01:01 -0700 (PDT) Date: Fri, 3 Apr 2026 13:00:53 +0800 From: Kairui Song To: kasong@tencent.com Cc: linux-mm@kvack.org, 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 09/14] mm/mglru: use the common routine for dirty/writeback reactivation Message-ID: References: <20260403-mglru-reclaim-v3-0-a285efd6ff91@tencent.com> <20260403-mglru-reclaim-v3-9-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-9-a285efd6ff91@tencent.com> Forwarding sashiko review, which seems not a real issue but just in case: > commit e6160f371a1c25f6b49b0a6639582d0636d9905b > Author: Kairui Song > mm/mglru: use the common routine for dirty/writeback reactivation > This commit drops MGLRU-specific handling for dirty and writeback folios, > instead allowing the common shrink_folio_list() routine to process and > reactivate them like the classical LRU. > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 9f4512a4d35fc..2a36cf937061b 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4628,21 +4627,6 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > > return true; > > } > > > > - dirty = folio_test_dirty(folio); > > - writeback = folio_test_writeback(folio); > > - if (type == LRU_GEN_FILE && dirty) { > > - sc->nr.file_taken += delta; > > - if (!writeback) > > - sc->nr.unqueued_dirty += delta; > > - } > > - > > - /* waiting for writeback */ > > - if (writeback || (type == LRU_GEN_FILE && dirty)) { > > - gen = folio_inc_gen(lruvec, folio, true); > > - list_move(&folio->lru, &lrugen->folios[gen][type][zone]); > > - return true; > > - } > Does removing this explicit promotion and instead falling back to > shrink_folio_list() cause these folios to retain stale tier bits? > When dirty and writeback folios are processed by shrink_folio_list(), > they frequently hit the activate_locked path, which sets PG_active on > the folio. > When these folios are returned in a list to evict_folios(), it tries to > clear stale tier bits by checking if the folio is from the oldest > generation: > if (lru_gen_folio_seq(lruvec, folio, false) == min_seq[type]) > Because PG_active is set, lru_gen_folio_seq() calculates a younger > generation, so this check evaluates to false and the tier bits > (LRU_REFS_FLAGS) are not cleared. > Later, the folios are added back to the LRU via move_folios_to_lru() and > lru_gen_add_folio(). While lru_gen_add_folio() clears PG_active, it > intentionally does not clear LRU_REFS_FLAGS. > Could this sequence leave the folios in a younger generation with stale > PG_referenced and LRU_REFS_MASK bits, artificially inflating their access > counts? Actually the new behavior is better I believe, clearing the ref bits for dirty folios make no sense. We even previously had a commit locally to disable resetting the refs bits for folio_inc_gen unless it's getting protected by ref bits (MGLRU's PID). The access count contributes to the PID protection, refault tracking and things like PSI, leave these counter untouched should help them to track the folio hotness info better upon the real reclaim when the writeback is done. I better mention this in the commit message indeed.