From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 AE6DF3B19D5 for ; Tue, 7 Apr 2026 14:26:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775571970; cv=none; b=fPemDD0VCpWIeLQpsmuzjD/L5LarOmpC7Z4PgBDKQLTltAcPWeBa5igPML8BruGOUafxLf/h5uJKcTkNSZajCe+lVceGIduklmurvxbBTTIU+BtzPFOjF3HqKUKYhEKrWWQLm+X44oiHkyFNZTBAlJwa0lFvY5YCFQXWFPP7C5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775571970; c=relaxed/simple; bh=829ZZ5E3wKP2+ZELBPhaNu/WQikZU0++2gsgVEiiPMQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k/LwPD7GERckieP07M2Iwzw4j3clzSVn+vFgUcxv3letXdJC6abFbPlAxftBoH1TMb2wwWp2p34OrylaA8ORSOpEmMSaU+gvNDprc0+xm07Tjme7axYJX1MKOMaKjYXJ/e+AfD0LTkkyjlTTMVp+MsdL1VSiMM+ztSovEHPZ7C8= 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=b+jVh5k/; arc=none smtp.client-ip=209.85.222.182 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="b+jVh5k/" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-8d68bcf50fdso304182385a.2 for ; Tue, 07 Apr 2026 07:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775571968; x=1776176768; 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=qGf/r/Eh13w4WKFfDtjUs5rckGZDNQIwgJJqFVJWp6g=; b=b+jVh5k/mh/Jm4TKchtDS1DN31c92mpq7TiPuNAMAHpgpiiWp9HvhSo7k6vYlSWxh2 ueKINgl0n9zsMRdSc0MTqOU+kT0RfF+8RJvRTHX/xiKxorDOT9teokknQLTwHUIGUsHo fpkqdf/Pjm0SIXucANF6H5u4J4crRXQGrHkubrJB9GxSahr1w/n3lSqcEf5HL5H/MhpG CZ5NMgigdxxkk5A3luZuPvKT/qMLvT5yR3ymCw1IKOIWn/zcTnKyUbEAOJQcuV6+QiVh GyUUMxBmqPMc3jXIEs2DFKXIEWiRncwW151MTzO/m2nJia59mNF4NDMxsaUTjM1WRGuM xZJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775571968; x=1776176768; 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=qGf/r/Eh13w4WKFfDtjUs5rckGZDNQIwgJJqFVJWp6g=; b=B4DE/UETPH3oH4zgmTcivJ1MTlu27EA0+sqAf8nKuF2UV1LTdLD1r4oVywbXceq+Yf D1wNlzWcsf4Qppj+7eRt6/qzRA9YKEps4/a16qE2R6qB2nH6iApH4IXK9fwVCj3BGltN Ke7GOYnMIbr9u4XNg1TquhUq97QsjEF+wMTq+QttVMyT4au2UTSruYurHTgLDyPbFTMb 7BdkGQ0WDs8LqA46k0tJllEPV9CeDFttO9MLi66WDiwElWOMQHug7dFd0aphRy3SR612 m8RmWNGfOb607l3CrUd7W/FCekXD0PN6SEv9dm8Y/FKPfY6ZCPfrBFJqfN0M8lwhrOdT Cr9g== X-Forwarded-Encrypted: i=1; AJvYcCWosxxK2u9ERZSdsCr+nyp337DTPbodkpen0pb6LnFzPz7FCotjJo3JJNwp9HfDaPZmWtHE7fu0iHL+4KY=@vger.kernel.org X-Gm-Message-State: AOJu0YymVKb1XqpvVEKuQWKxpsst69YBZtD4ljg8Zv45I+HoboAwUX0c bJfgRiZAGZJq7U2qMme8Z+CNa1kUEWjkEWpTe70q+J/Af79catf0LW4S X-Gm-Gg: AeBDievE08ISUJxQX/nx4Vp47cbdHYTBT3aSC/MJ8EdF1LKIhYpIsQEt4De0lYFcQsk MSvft/koglnI0klU7ch+sxxxxkArVPgeIYsUfRBrF+6ldd4vi1mffrNg28BV+DqiegvwSA6rqz6 yamgRf21aQhFcMywssUkdoSTIiYWIHQKgmxsreOrGvliSuykNApK95ffGeYnapLf2bHA0ZSPQsR 0czWOjJQUCd6CRgpV2HBLxL+LGjEvc/oIe98dc7Ol5lxnXOuQM58MR1rPXMG9OsBjqDNgrMRS3g rzs8Az2rnO1Ia6XuXMTrQlvncQ3ZcuvyR+E1RtBvU/Ffy6NChV1JR8PKDI1Wtql/tz/u9V4kxal Asi5OpNAlNbPFhN7wRabedObfx8NQ/+sW1eEaEDmFWs3Su9rwYie0/F/NdeBv8HQbFcm6xYELim 7RpyqfzkyJU3N7asVasxqucQbtexTh92oP40VcSFkjZ/QFkNmpOp6jrCNRMF8= X-Received: by 2002:a05:620a:7016:b0:8da:cfe6:c67c with SMTP id af79cd13be357-8dacfe6ced5mr4740085a.28.1775571967485; Tue, 07 Apr 2026 07:26:07 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8d2a8067d16sm1240636785a.31.2026.04.07.07.26.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 07:26:06 -0700 (PDT) Date: Tue, 7 Apr 2026 22:25:58 +0800 From: Kairui Song To: wangzhen Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Axel Rasmussen , Yuanchu Xie , Wei Xu , "kasong@tencent.com" , "baolin.wang@linux.alibaba.com" , "baohua@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH RFC] mm/vmscan:Fix the hot/cold inversion when swappiness = 0 or 201 Message-ID: References: <7829b070df1b405dbc97dd6a028d8c8a@honor.com> <4451bdc432864aebb54f401eee51ea53@honor.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: <4451bdc432864aebb54f401eee51ea53@honor.com> On Tue, Apr 07, 2026 at 01:37:08PM +0800, wangzhen wrote: > >From ac731b061f152cba05b9aa351652a04f933986e0 Mon Sep 17 00:00:00 2001 > From: w00021541 > Date: Tue, 7 Apr 2026 16:17:53 +0800 > Subject: [PATCH RFC] mm/vmscan:Fix the hot/cold inversion when swappiness = 0 or 201 > > In some cases, when swappiness is set to 0 or 201, the oldest generation pages will be changed to the newest generation incorrectly. > > Consider the following aging scenario: > MAX_NR_GENS=4, MIN_NR_GENS=2, swappiness=201, 3 anon gens, 4 file gens. > 1. When swappiness = 201, should_run_aging will only check anon type. > should_run_aging return true. > 2. In inc_max_seq, if the anon and file type have MAX_NR_GENS, inc_min_seq will move the oldest generation pages to the second oldest to prepare for increasing max_seq. > Here, the file type will enter inc_min_seq. > 3. In inc_min_seq, first goto is true, the pages migration was skipped, resulting in the inversion of cold/hot pages. > > In fact, when MAX_NR_GENS=4 and MIN_NR_GENS=2, the for loop after the goto is unreachable. > > Consider the code in inc_max_seq: > if (get_nr_gens(lruvec, type) ! = MAX_NR_GENS) > continue; > This means that only get_nr_gens==4 can enter the inc_min_seq. > > Discuss the swappiness in three different scenarios: > 1<=swappiness<=200: > If should_run_aging returns true, both anon and file types must satisfy get_nr_gens<=3, indicating that no type satisfies get_nr_gens==MAX_NR_GENS. > Therefore, both cannot enter inc_min_seq. > > swappiness=201: > If should_run_aging returns true, the anon type must satisfy get_nr_gens<=3. Only file type can satisfy get_nr_gens==MAX_NR_GENS. > After entering inc_min_seq, type && (swappiness == SWAPPINESS_ANON_ONLY) is true, the for loop will be skipped. > > swappiness=0: > Same as swappiness=201 > > so the two goto statements should be removed. This ensures that when swappiness=0 or 201, the oldest generation pages are correctly promoted to the second oldest generation. > (When 1<= swappiness<=200, only both anon and file types get_nr_gens<=3 will age, preventing the inversion of hot/cold pages). > > Signed-off-by: w00021541 > --- > mm/vmscan.c | 14 +++----------- > 1 file changed, 3 insertions(+), 11 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 0fc9373e8251..54c835b07d3e 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3843,7 +3843,7 @@ static void clear_mm_walk(void) > kfree(walk); > } > > -static bool inc_min_seq(struct lruvec *lruvec, int type, int swappiness) > +static bool inc_min_seq(struct lruvec *lruvec, int type) > { > int zone; > int remaining = MAX_LRU_BATCH; > @@ -3851,14 +3851,6 @@ static bool inc_min_seq(struct lruvec *lruvec, int type, int swappiness) > int hist = lru_hist_from_seq(lrugen->min_seq[type]); > int new_gen, old_gen = lru_gen_from_seq(lrugen->min_seq[type]); > > - /* For file type, skip the check if swappiness is anon only */ > - if (type && (swappiness == SWAPPINESS_ANON_ONLY)) > - goto done; > - > - /* For anon type, skip the check if swappiness is zero (file only) */ > - if (!type && !swappiness) > - goto done; > - Hi, thanks for the patch. We have a very similar patch internally, and the result is kind of bad. Currently MGLRU forbid the gen distance between file and anon go larger than 2, which mean with this patch, when under great pressure, you may have to keep rotating a long list of the opposite type of folios to reclaim another type. For example, when you have only 2 gens of file folios, swap disabled, and there are 3 gens of anon folios. Anon folios are unevictable because there is no SWAP. And file is also unevcitable due to force protection of gen. Consider anon folios are mostly cold (at least a portion of them are), now the oldest gen of anon folios will be very long (e.g. 12G, 3145728 folios). Now, to reclaim any file folios, you have to age first. Before this patch that is usually fast. But after this, it will have to rotate all 3145728 folios to second oldest anon gen, will could take a very long time. During that period any concurrent reclaimer will get rejected due to force protection, result in very ugly long tailing or unexpected OOM. So I agree this is a good idea in general, I agree we should do this. But better defer this until we patch up MGLRU to remove the force protection first. But I think it might be reasonable to remove the SWAPPINESS_ANON_ONLY limit now, that can only be triggered by proactive reclaim which would tolerate long tailing and won't cause OOM.