From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-156.mta1.migadu.com [95.215.58.156]) (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 8CA4639280A for ; Wed, 26 Aug 2026 08:57:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.156 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787734623; cv=none; b=r+s/Jeh8YanL2jrMfCPjTT/rrsjcUuqz/SNOWROFC69h5iNbCSolZLFJi5GmN5lcP5VdH4A/kfYYcLB+xcyDsuN7DAT+D9hSKL0sZ9EwxZ2tvB6kIkiOuYw7Cn4VD7LxdvZJhy4GovNFc/yHTevA0RSwxj2RUW1Axv+SnJqIYHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787734623; c=relaxed/simple; bh=YvE7TMRi8YUbvrIcqXRmL+ykNziy5hMN0bDbJpNCV+8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ogaRGVz6H3yYTwqVFA9DIxLoCsG1xurSeLhhIBl4ejHO5AWNdvxkIwOB8Uue3/rZKAxJyOUSloHlkuhs/+JLNkDylwJ2TuTfo/kUF96sBLXHK7z40sclaBOrx7jbwDD/eW3MfieusNaHttDtZ7r7jbQ+fte+QaNRUzHMuX0O8sw= 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=hd0S+ReH; arc=none smtp.client-ip=95.215.58.156 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="hd0S+ReH" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=YvE7TMRi8YUbvrIcqXRmL+ykNziy5hMN0bDbJpNCV+8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787734618; v=1; x=1788339418; b=hd0S+ReHrtZAQjA1R7kX0pxmIJugVw24d/M0aOhbST6Kuyvi5A3dDkgyYb+9x+nAJG347Z5r YPi63Hain4f10CcyX9HBzKGcZg/SaN3Fh6lpnHbHgZv511VmCs4r2jhxTahv7GV1L0hfSWPIhqA 4P4yDWoi2K2d9kI2fXNhMJ00= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (223.70.159.239) by mta10.migadu.com with ESMTPS id fdcb0e4ec58e3f29; Wed, 26 Aug 2026 08:56:48 +0000 X-Mizu-Trace-ID: fdcb0e4ec58e3f29 X-Migadu-Flow: FLOW_OUT Date: Wed, 26 Aug 2026 16:56:45 +0800 From: Baoquan He To: "Barry Song (Xiaomi)" Cc: akpm@linux-foundation.org, linux-mm@kvack.org, axelrasmussen@google.com, baolin.wang@linux.alibaba.com, chenridong@xiaomi.com, david@kernel.org, hannes@cmpxchg.org, kasong@tencent.com, lianux.mm@gmail.com, linux-kernel@vger.kernel.org, ljs@kernel.org, lyugaofei@xiaomi.com, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, stevensd@chromium.org, wangzicheng@honor.com, weixugc@google.com, yuanchu@google.com, zhangbo56@xiaomi.com Subject: Re: [PATCH 3/6] mm/mglru: enhance cold/hot inversion handling in inc_min_seq() Message-ID: References: <20260821102538.22642-1-baohua@kernel.org> <20260821102538.22642-4-baohua@kernel.org> 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: <20260821102538.22642-4-baohua@kernel.org> On 08/21/26 at 06:25pm, Barry Song (Xiaomi) wrote: > During aging, a folio's generation may already have been updated by > folio_update_gen(), even though it has not yet been moved to the > corresponding generation list. Such folios are hotter than those > already in that generation. > > It makes sense for inc_min_seq() to increment the generation of > folios that were never promoted during aging and move them to the > tail of the new oldest generation. However, folios that were already > promoted should instead be moved to the head of their updated > generation, just as sort_folio() does in scan_folios(). While sort_folio() move protected folio to the head of next gen too. It only moves ineligible folios to the tail of next gen. > > Otherwise, promoted folios could end up behind folios that were > never promoted, effectively inverting their hot/cold ordering. > > Signed-off-by: Barry Song (Xiaomi) > --- > mm/vmscan.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 99ee3c833d54..3b618a51cde2 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3946,9 +3946,12 @@ static bool inc_min_seq(struct lruvec *lruvec, int type, int swappiness) > VM_WARN_ON_ONCE_FOLIO(folio_zonenum(folio) != zone, folio); > > new_gen = __folio_inc_gen(folio, old_gen, &gen_increased); > - list_move_tail(&folio->lru, &lrugen->folios[new_gen][type][zone]); > - if (gen_increased) > + if (gen_increased) { > delta += nr_pages; > + list_move_tail(&folio->lru, &lrugen->folios[new_gen][type][zone]); > + } else { > + list_move(&folio->lru, &lrugen->folios[new_gen][type][zone]); > + } > /* don't count the workingset being lazily promoted */ > if (refs + workingset != BIT(LRU_REFS_WIDTH) + 1) { > int tier = lru_tier_from_refs(refs, workingset); > -- > 2.34.1 >