From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2381C8303D for ; Wed, 2 Jul 2025 02:08:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 765CF6B00D0; Tue, 1 Jul 2025 22:08:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73E036B00D1; Tue, 1 Jul 2025 22:08:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 653126B00D2; Tue, 1 Jul 2025 22:08:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 52BE96B00D0 for ; Tue, 1 Jul 2025 22:08:50 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 26B081246A5 for ; Wed, 2 Jul 2025 02:08:50 +0000 (UTC) X-FDA: 83617691220.11.17A57ED Received: from sg-1-39.ptr.blmpb.com (sg-1-39.ptr.blmpb.com [118.26.132.39]) by imf23.hostedemail.com (Postfix) with ESMTP id A42BA140007 for ; Wed, 2 Jul 2025 02:08:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=lixiang-com.20200927.dkim.feishu.cn header.s=s1 header.b=jmzb5uoE; spf=pass (imf23.hostedemail.com: domain of jiahao1@lixiang.com designates 118.26.132.39 as permitted sender) smtp.mailfrom=jiahao1@lixiang.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751422128; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Dhy0e3JbbJTRmVS8Mid+FimyJ9vPyM7vIOo8AzemeTg=; b=ueXwxIpgIb7CYvWJcucfzcVEsvy3d48VGefC+Zvk9Wuq/DWBc6rIMzyoB8aOPrBz2t84rb tgEwB2yzl8gnKftB4qxlsxN117rJiZzxvgbN3sPICPX7h+ek0t5rrUuFhlkCdRc7AZaAuY sytYTSZvgVhYFckJgAuCq30UoBEw+JE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751422128; a=rsa-sha256; cv=none; b=NK7lLJt7nk10bNzPM54C5PdpM2HdmQwKW1Ry2i81C6oUhVnR/OTT/aiiGlrG8NNdxyqRff Ci5WLJdOVl4UFkdrn+KY6558d3C+U/brJE2cdfb4uVdt02i/fMTaqGSMQcgjpYE4Ah4Owu YpsyzwmglaeEymjUpXeaQ6KrxVxdbc4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=lixiang-com.20200927.dkim.feishu.cn header.s=s1 header.b=jmzb5uoE; spf=pass (imf23.hostedemail.com: domain of jiahao1@lixiang.com designates 118.26.132.39 as permitted sender) smtp.mailfrom=jiahao1@lixiang.com; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=lixiang-com.20200927.dkim.feishu.cn; t=1751422114; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=Dhy0e3JbbJTRmVS8Mid+FimyJ9vPyM7vIOo8AzemeTg=; b=jmzb5uoE8zH3DKbyLIOiBx41XTHsdOox7faFurxGeQtz4VTeE/ZbxGaDakHDguH5eKPQJ7 cR2Z5xjwxyX6vvPVT/pGB+ZDy2fMK21DKIFXRfNvLTGdl3iW8lbxatZaDN5nQXz/v+7mEI kjdrE4mBk1M2iuGDPxifvl/FUpxF8KQIDlB53UP08N5k6HApOw45ZO7RQj19RFvw1wysyn Hm3HGOLhr478XdMo9kYRv5EdEZO51meNsFcc9u1Btzpv2gfeIBxB0G/zmnY/kXP28QpQyC LeQehaHA6SeDjO7BEJ1m9qPQBHylOXIVNDqtwa6MuQv3zZDy4bohpZqoZcqIIw== Mime-Version: 1.0 In-Reply-To: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 X-Original-From: Hao Jia Date: Wed, 2 Jul 2025 10:08:29 +0800 Received: from [10.125.192.71] ([60.190.250.155]) by smtp.feishu.cn with ESMTPS; Wed, 02 Jul 2025 10:08:30 +0800 References: <20250630080603.36171-1-jiahao.kernel@gmail.com> To: "Yuanchu Xie" , "Hao Jia" Cc: , , , , , , , , , , From: "Hao Jia" Content-Transfer-Encoding: 8bit X-Lms-Return-Path: Subject: Re: [PATCH] mm/mglru: Stop try_to_inc_min_seq() if the oldest generation LRU lists are not empty Message-Id: <1b4c661a-b370-316c-edc9-6c99eab9e210@lixiang.com> Content-Type: multipart/alternative; boundary=d5e97d192149064169ec60aea4a82b424e1b1c67836fec0bce197e8cbfac X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A42BA140007 X-Stat-Signature: 6r9gat5tz8gbhhdfqptqsw6wmffo64e3 X-HE-Tag: 1751422126-968247 X-HE-Meta: U2FsdGVkX1+TKQhJK1eVkbSokWZ8YWFGw46wH0XUNvtSbnJjBh4zfK/fDrfY6xcnoqDOOVxaE3oqp/8Ux8W1PVxi8hBANnafKk1bfH/TWjclyzW631yYZRyPqyvtCePrTfDCcjWpbUWLW/dKDbUm8Hl5+BLXWcZKZ4plIszDpNKTfECOKI6qAQFwnDVXsEjqH0mocuplYl5UTSRXW0WXT1BoELcOzWL5rjl4t9yQIWEO5IZap8jkcA0ffygIbRvFdeStYGgFewrK2XFhpCzBM9VjaSuYUBrHeojshkRo3VAXffxEPWpQBpQgk+8ZpuRVXxVbkakhxW/Cop8KN/XtfF8zY1sYVVCUuw8JkiueqCUQMPIIw8gjEUVMAi8q1u0JQgY257/eLk35wI+XjvKbuxKiXtXUNRLV1AuCinjT6qppZTJC3sXjS+6WAFFBb7GhRiiHCH7wJWGAHwZEUmtZ8fn0kJlpryB0kkyG6klwdSKbTI1qxFNugGQiAQr8g/So/UMVgP/+DIdSSj8q1ceesSNzpYMGEGAvPShi1Q/Xhe/GTGFcOdlmSKxZutyVUONqWc+b1QVMiuUGmdYlQUjD+zCruq6nPt/sGpWMfsGqYBj95pXzMRzFkv75Y8/0mRZTK+bPHvvcT+xXzMD06QZKDTI55cOd4AgbznkRSv0V2TYLsUci0fKN4r88sxnbbA4ZN41xqxU8h/fiaLDG+otf2MXCsn+WxA8i0TMi6KT+pmVC/w6BKkXXpnNoqPaUgoe7X7mqVgDaDJh67TUBGa3wA2OmtD6B9t5x72snhbaw64/p7dJigkgwbNCXNlAsSkToYmvpc33nRNYHKIIZnR8cpvhDWcpn6emlQy7+SYH6pZVg1dSlSCXDOJ6rOxb316nhLD5bXuD3onH+9f672zoS+wQwrB2ObLMCfvSPwGICizAL1gtbkS59OWYbGvw8UNtI1pcS7xW+kUVA/+yMpvL 3f4N6KRo fT2OsMeSXHWFi2zSB0jhugo21yfdVx3fX9A0Wv6TRkOaMJOXRWg0Y8g76+smY1QJ0+/WEmzPyjCrPOsODBB02bPkUcknhVN6LngOCoMq2KoReOBDn6LO/ZGxmZMg9UpI31ZojbFCKWZmuhQrGSyiQhsLBi857afxh0GiBhg8ePlEVFtce++2VfWD+Xg4TaG1w1twGW3UfgM/i7BcYVnMEc3D1LJ9vv6tZ2cQ8vNC7n/AkuzTfixmnMRLevwH8F2ahDcrWWH9qRKzDWC6c27Q9ryk6NaMKiNwBVsVQdC36lNthn3804ilsJ6W0ki+gZkwGUy5IfmrhkPG0hCDSimSPzohdkBKXLs8xT4aCR9QoH/HHhwEMSUQBW2caJ5qdurGl9vrXf7dqdoe/MFfadFIrte38jLA8CtAnmj/gmWTnLnsn0kbIIyO77qBk4ndsnRg7qUP5kDVbTL0kZNvGtPLZ4a6EfW64iWlO2nB3VUe8kc18vOJdz0UB6ctuofPRN4uZFtlp0ZnQXw/hrik= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --d5e97d192149064169ec60aea4a82b424e1b1c67836fec0bce197e8cbfac Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On 2025/7/2 08:31, Yuanchu Xie wrote: > On Mon, Jun 30, 2025 at 1:06=E2=80=AFAM Hao Jia = wrote: >> >> From: Hao Jia >> >> In try_to_inc_min_seq(), if the oldest generation of LRU lists >> (anonymous and file) are not empty. Then we should return directly >> to avoid unnecessary subsequent overhead. >> >> Corollary: If the lrugen->folios[gen][type][zone] lists of both >> anonymous and file are not empty, try_to_inc_min_seq() will fail. >> >> Proof: Taking LRU_GEN_ANON as an example, consider the following two cas= es: >> >> Case 1: min_seq[LRU_GEN_ANON] <=3D seq (seq is lrugen->max_seq - MIN_NR_= GENS) >> >> Since min_seq[LRU_GEN_ANON] has not increased, >> so min_seq[LRU_GEN_ANON] is still equal to lrugen->min_seq[LRU_GEN_ANON]= . >> Therefore, in the following judgment: >> min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is always true. >> So, we will not increase the seq of the oldest generation of anonymous, >> and try_to_inc_min_seq() will return false. >> >> case 2: min_seq[LRU_GEN_ANON] > seq (seq is lrugen->max_seq - MIN_NR_GEN= S) >> >> If min_seq[LRU_GEN_ANON] > seq, that is, lrugen->min_seq[LRU_GEN_ANON] >= seq > This part doesn't make sense to me. > The code is as follows: >=20 > /* find the oldest populated generation */ > for_each_evictable_type(type, swappiness) { > while (min_seq[type] + MIN_NR_GENS <=3D lrugen->max_seq) { > gen =3D lru_gen_from_seq(min_seq[type]); >=20 > for (zone =3D 0; zone < MAX_NR_ZONES; zone++) { > if (!list_empty(&lrugen->folios[gen][type][zone])) > goto next; > } >=20 > min_seq[type]++; > } >=20 > Here, it could be that , min_seq[type] > lrugen->max_seq - MIN_NR_GENS > (what you refer to as seq) > However, this is a result of incrementing a copy of > lrugen->min_seq[type] as this piece of code finds the oldest populated > generation. >=20 Hi, Yuanchu Sorry for the confusion. I am assuming that if the oldest generation LRU lists (anonymous and=20 file) are not empty, in other words, *min_seq[type]* has not increased. The above part has been executed, and it is known that min_seq[type] has=20 not increased=EF=BC=88that is, min_seq[type]=3Dlrugen->min_seq[type] at thi= s=20 time=EF=BC=89, so the rest of the reasoning. Maybe you mean that under the above premise min_seq[type] is impossible=20 to be greater than seq (seq is lrugen->max_seq - MIN_NR_GENS)? If so, case2 does not need to be discussed and reasoned. In either case, my patch will work well. Thanks, Hao > next: > ; > } >=20 >> Then min_seq[LRU_GEN_ANON] is assigned seq. > This is not necessarily true, because swappiness can be 0, and the > assignments happen to prevent one LRU type from going more than 1 gen > past the other. > so if `min_seq[LRU_GEN_ANON] > seq && min_seq[LRU_GEN_FILE] =3D=3D seq` i= s > true, then min_seq[LRU_GEN_ANON] is not assigned seq. Yes, if min_seq[LRU_GEN_ANON] is not assigned seq, then the situation is=20 the same as case 1. min_seq[LRU_GEN_ANON] is equal to=20 lrugen->min_seq[LRU_GEN_ANON]. in the following judgment: min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is always true. Case 2 wants to discuss another situation, that is, when=20 min_seq[LRU_GEN_ANON] is assigned to seq. The following judgment is=20 whether min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is always= =20 true. >=20 >=20 >> Therefore, in the following judgment: >> min_seq[LRU_GEN_ANON] (seq) <=3D lrugen->min_seq[LRU_GEN_ANON] is always= true. >> So, we will not update the oldest generation seq of anonymous, >> and try_to_inc_min_seq() will return false. >> >> It is similar for LRU_GEN_FILE. Therefore, in try_to_inc_min_seq(), >> if the oldest generation LRU lists (anonymous and file) are not empty, >> in other words, min_seq[type] has not increased. >> we can directly return false to avoid unnecessary checking overhead late= r. > Yeah I don't think this proof holds. If you think it does please > elaborate more and make your assumptions more clear. >=20 >> >> Signed-off-by: Hao Jia >> --- >> mm/vmscan.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index f8dfd2864bbf..3ba63d87563f 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -3928,6 +3928,7 @@ static bool try_to_inc_min_seq(struct lruvec *lruv= ec, int swappiness) >> int gen, type, zone; >> bool success =3D false; >> struct lru_gen_folio *lrugen =3D &lruvec->lrugen; >> + int seq_inc_flags[ANON_AND_FILE] =3D {0}; >> DEFINE_MIN_SEQ(lruvec); >> >> VM_WARN_ON_ONCE(!seq_is_valid(lruvec)); >> @@ -3943,11 +3944,20 @@ static bool try_to_inc_min_seq(struct lruvec *lr= uvec, int swappiness) >> } >> >> min_seq[type]++; >> + seq_inc_flags[type] =3D 1; >> } >> next: >> ; >> } >> >> + /* >> + * If the oldest generation of LRU lists (anonymous and file) >> + * are not empty, we can directly return false to avoid unnecess= ary >> + * checking overhead later. >> + */ >> + if (!seq_inc_flags[LRU_GEN_ANON] && !seq_inc_flags[LRU_GEN_FILE]= ) >> + return success; >> + >> /* see the comment on lru_gen_folio */ >> if (swappiness && swappiness <=3D MAX_SWAPPINESS) { >> unsigned long seq =3D lrugen->max_seq - MIN_NR_GENS; >> -- >> 2.34.1 >> >> > I don't understand what problem this patch tries to solve. >=20 > Yuanchu My pathch is that if we already know that min_seq[type] (including=20 anonymous and file) has not increased, we can directly let=20 try_to_inc_min_seq() return failure to reduce unnecessary checking=20 overhead later. After my above reasoning, this does not change the=20 original behavior of try_to_inc_min_seq(). I added some code to count the number of try_to_inc_min_seq() calls and=20 the number of times the situation mentioned in my patch is hit. Run the test in tools/testing/selftests/cgroup/test_memcontrol on my=20 machine. hit_cnt: 1215 total_cnt: 1702 The hit rate is about 71% Thanks, Hao =E5=A3=B0=E6=98=8E=EF=BC=9A=E8=BF=99=E5=B0=81=E9=82=AE=E4=BB=B6=E5=8F=AA=E5= =85=81=E8=AE=B8=E6=96=87=E4=BB=B6=E6=8E=A5=E6=94=B6=E8=80=85=E9=98=85=E8=AF= =BB=EF=BC=8C=E6=9C=89=E5=BE=88=E9=AB=98=E7=9A=84=E6=9C=BA=E5=AF=86=E6=80=A7= =E8=A6=81=E6=B1=82=E3=80=82=E7=A6=81=E6=AD=A2=E5=85=B6=E4=BB=96=E4=BA=BA=E4= =BD=BF=E7=94=A8=E3=80=81=E6=89=93=E5=BC=80=E3=80=81=E5=A4=8D=E5=88=B6=E6=88= =96=E8=BD=AC=E5=8F=91=E9=87=8C=E9=9D=A2=E7=9A=84=E4=BB=BB=E4=BD=95=E5=86=85= =E5=AE=B9=E3=80=82=E5=A6=82=E6=9E=9C=E6=9C=AC=E9=82=AE=E4=BB=B6=E9=94=99=E8= =AF=AF=E5=9C=B0=E5=8F=91=E7=BB=99=E4=BA=86=E4=BD=A0=EF=BC=8C=E8=AF=B7=E8=81= =94=E7=B3=BB=E9=82=AE=E4=BB=B6=E5=8F=91=E5=87=BA=E8=80=85=E5=B9=B6=E5=88=A0= =E9=99=A4=E8=BF=99=E4=B8=AA=E6=96=87=E4=BB=B6=E3=80=82=E6=9C=BA=E5=AF=86=E5= =8F=8A=E6=B3=95=E5=BE=8B=E7=9A=84=E7=89=B9=E6=9D=83=E5=B9=B6=E4=B8=8D=E5=9B= =A0=E4=B8=BA=E8=AF=AF=E5=8F=91=E9=82=AE=E4=BB=B6=E8=80=8C=E6=94=BE=E5=BC=83= =E6=88=96=E4=B8=A7=E5=A4=B1=E3=80=82=E4=BB=BB=E4=BD=95=E6=8F=90=E5=87=BA=E7= =9A=84=E8=A7=82=E7=82=B9=E6=88=96=E6=84=8F=E8=A7=81=E5=8F=AA=E5=B1=9E=E4=BA= =8E=E4=BD=9C=E8=80=85=E7=9A=84=E4=B8=AA=E4=BA=BA=E8=A7=81=E8=A7=A3=EF=BC=8C= =E5=B9=B6=E4=B8=8D=E4=B8=80=E5=AE=9A=E4=BB=A3=E8=A1=A8=E6=9C=AC=E5=85=AC=E5= =8F=B8=E3=80=82 Disclaimer: This email is intended to be read only by the designated recipi= ent of the document and has high confidentiality requirements. Anyone else = is prohibited from using, opening, copying or forwarding any of the content= s inside. If this email was sent to you by mistake, please contact the send= er of the email and delete this file immediately. Confidentiality and legal= privileges are not waived or lost by misdirected emails. Any views or opin= ions expressed in the email are those of the author and do not necessarily = represent those of the Company. --d5e97d192149064169ec60aea4a82b424e1b1c67836fec0bce197e8cbfac Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2025/7/2 08:31, Yuanchu Xie wrote:
> On Mon, Jun 30, 2025 at 1:06=E2=80=AFAM Hao Jia wrote:
>>
>> From: Hao Jia
>>
>> In try_to_inc_min_seq(), if the oldest generation of LRU lists
>> (anonymous and file) are not empty. Then we should return directly
>> to avoid unnecessary subsequent overhead.
>>
>> Corollary: If the lrugen->folios[gen][type][zone] lists of both
>> anonymous and file are not empty, try_to_inc_min_seq() will fail.
>>
>> Proof: Taking LRU_GEN_ANON as an example, consider the following two= cases:
>>
>> Case 1: min_seq[LRU_GEN_ANON] <=3D seq (seq is lrugen->max_seq - MIN= _NR_GENS)
>>
>> Since min_seq[LRU_GEN_ANON] has not increased,
>> so min_seq[LRU_GEN_ANON] is still equal to lrugen->min_seq[LRU_GEN_A= NON].
>> Therefore, in the following judgment:
>> min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is always t= rue.
>> So, we will not increase the seq of the oldest generation of anonymo= us,
>> and try_to_inc_min_seq() will return false.
>>
>> case 2: min_seq[LRU_GEN_ANON] > seq (seq is lrugen->max_seq - MIN_NR= _GENS)
>>
>> If min_seq[LRU_GEN_ANON] > seq, that is, lrugen->min_seq[LRU_GEN_ANO= N] > seq
> This part doesn't make sense to me.
> The code is as follows:
>=20
> /* find the oldest populated generation */
> for_each_evictable_type(type, swappiness) {
> while (min_seq[type] + MIN_NR_GENS <=3D lrugen->max_seq) {
> gen =3D lru_gen_from_seq(min_seq[type]);
>=20
> for (zone =3D 0; zone < MAX_NR_ZONES; zone++) {
> if (!list_empty(&lrugen->folios[gen][type][zone]))
> goto next;
> }
>=20
> min_seq[type]++;
> }
>=20
> Here, it could be that , min_seq[type] > lrugen->max_seq - MIN_NR_GEN= S
> (what you refer to as seq)
> However, this is a result of incrementing a copy of
> lrugen->min_seq[type] as this piece of code finds the oldest populate= d
> generation.
>=20

Hi, Yuanchu

Sorry for the confusion.

I am assuming that if the oldest generation LRU lists (anonymous and=20
file) are not empty, in other words, *min_seq[type]* has not increased.

The above part has been executed, and it is known that min_seq[type] ha= s=20
not increased=EF=BC=88that is, min_seq[type]=3Dlrugen->min_seq[type] at= this=20
time=EF=BC=89, so the rest of the reasoning.

Maybe you mean that under the above premise min_seq[type] is impossible= =20
to be greater than seq (seq is lrugen->max_seq - MIN_NR_GENS)?
If so, case2 does not need to be discussed and reasoned.

In either case, my patch will work well.

Thanks,
Hao

> next:
> ;
> }
>=20
>> Then min_seq[LRU_GEN_ANON] is assigned seq.
> This is not necessarily true, because swappiness can be 0, and the
> assignments happen to prevent one LRU type from going more than 1 gen
> past the other.
> so if `min_seq[LRU_GEN_ANON] > seq && min_seq[LRU_GEN_FILE] =3D=3D se= q` is
> true, then min_seq[LRU_GEN_ANON] is not assigned seq.

Yes, if min_seq[LRU_GEN_ANON] is not assigned seq, then the situation i= s=20
the same as case 1. min_seq[LRU_GEN_ANON] is equal to=20
lrugen->min_seq[LRU_GEN_ANON].
in the following judgment:
min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is always true= .


Case 2 wants to discuss another situation, that is, when=20
min_seq[LRU_GEN_ANON] is assigned to seq. The following judgment is=20
whether min_seq[LRU_GEN_ANON] <=3D lrugen->min_seq[LRU_GEN_ANON] is alw= ays=20
true.


>=20
>=20
>> Therefore, in the following judgment:
>> min_seq[LRU_GEN_ANON] (seq) <=3D lrugen->min_seq[LRU_GEN_ANON] is al= ways true.
>> So, we will not update the oldest generation seq of anonymous,
>> and try_to_inc_min_seq() will return false.
>>
>> It is similar for LRU_GEN_FILE. Therefore, in try_to_inc_min_seq(),
>> if the oldest generation LRU lists (anonymous and file) are not empt= y,
>> in other words, min_seq[type] has not increased.
>> we can directly return false to avoid unnecessary checking overhead = later.
> Yeah I don't think this proof holds. If you think it does please
> elaborate more and make your assumptions more clear.


>=20
>>
>> Signed-off-by: Hao Jia
>> ---
>> mm/vmscan.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index f8dfd2864bbf..3ba63d87563f 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -3928,6 +3928,7 @@ static bool try_to_inc_min_seq(struct lruvec *= lruvec, int swappiness)
>> int gen, type, zone;
>> bool success =3D false;
>> struct lru_gen_folio *lrugen =3D &lruvec->lrugen;
>> + int seq_inc_flags[ANON_AND_FILE] =3D {0};
>> DEFINE_MIN_SEQ(lruvec);
>>
>> VM_WARN_ON_ONCE(!seq_is_valid(lruvec));
>> @@ -3943,11 +3944,20 @@ static bool try_to_inc_min_seq(struct lruvec= *lruvec, int swappiness)
>> }
>>
>> min_seq[type]++;
>> + seq_inc_flags[type] =3D 1;
>> }
>> next:
>> ;
>> }
>>
>> + /*
>> + * If the oldest generation of LRU lists (anonymous and file= )
>> + * are not empty, we can directly return false to avoid unne= cessary
>> + * checking overhead later.
>> + */
>> + if (!seq_inc_flags[LRU_GEN_ANON] && !seq_inc_flags[LRU_GEN_F= ILE])
>> + return success;
>> +
>> /* see the comment on lru_gen_folio */
>> if (swappiness && swappiness <=3D MAX_SWAPPINESS) {
>> unsigned long seq =3D lrugen->max_seq - MIN_NR_GENS= ;
>> --
>> 2.34.1
>>
>>
> I don't understand what problem this patch tries to solve.
>=20
> Yuanchu

My pathch is that if we already know that min_seq[type] (including=20
anonymous and file) has not increased, we can directly let=20
try_to_inc_min_seq() return failure to reduce unnecessary checking=20
overhead later. After my above reasoning, this does not change the=20
original behavior of try_to_inc_min_seq().

I added some code to count the number of try_to_inc_min_seq() calls and= =20
the number of times the situation mentioned in my patch is hit.

Run the test in tools/testing/selftests/cgroup/test_memcontrol on my=20
machine.

hit_cnt: 1215 total_cnt: 1702
The hit rate is about 71%

Thanks,
Hao


<= div style=3D"text-align: left;">= =E5=A3=B0=E6=98=8E=EF=BC=9A=E8=BF=99=E5=B0=81=E9=82=AE=E4=BB=B6=E5=8F=AA=E5= =85=81=E8=AE=B8=E6=96=87=E4=BB=B6=E6=8E=A5=E6=94=B6=E8=80=85=E9=98=85=E8=AF= =BB=EF=BC=8C=E6=9C=89=E5=BE=88=E9=AB=98=E7=9A=84=E6=9C=BA=E5=AF=86=E6=80=A7= =E8=A6=81=E6=B1=82=E3=80=82=E7=A6=81=E6=AD=A2=E5=85=B6=E4=BB=96=E4=BA=BA=E4= =BD=BF=E7=94=A8=E3=80=81=E6=89=93=E5=BC=80=E3=80=81=E5=A4=8D=E5=88=B6=E6=88= =96=E8=BD=AC=E5=8F=91=E9=87=8C=E9=9D=A2=E7=9A=84=E4=BB=BB=E4=BD=95=E5=86=85= =E5=AE=B9=E3=80=82=E5=A6=82=E6=9E=9C=E6=9C=AC=E9=82=AE=E4=BB=B6=E9=94=99=E8= =AF=AF=E5=9C=B0=E5=8F=91=E7=BB=99=E4=BA=86=E4=BD=A0=EF=BC=8C=E8=AF=B7=E8=81= =94=E7=B3=BB=E9=82=AE=E4=BB=B6=E5=8F=91=E5=87=BA=E8=80=85=E5=B9=B6=E5=88=A0= =E9=99=A4=E8=BF=99=E4=B8=AA=E6=96=87=E4=BB=B6=E3=80=82=E6=9C=BA=E5=AF=86=E5= =8F=8A=E6=B3=95=E5=BE=8B=E7=9A=84=E7=89=B9=E6=9D=83=E5=B9=B6=E4=B8=8D=E5=9B= =A0=E4=B8=BA=E8=AF=AF=E5=8F=91=E9=82=AE=E4=BB=B6=E8=80=8C=E6=94=BE=E5=BC=83= =E6=88=96=E4=B8=A7=E5=A4=B1=E3=80=82=E4=BB=BB=E4=BD=95=E6=8F=90=E5=87=BA=E7= =9A=84=E8=A7=82=E7=82=B9=E6=88=96=E6=84=8F=E8=A7=81=E5=8F=AA=E5=B1=9E=E4=BA= =8E=E4=BD=9C=E8=80=85=E7=9A=84=E4=B8=AA=E4=BA=BA=E8=A7=81=E8=A7=A3=EF=BC=8C= =E5=B9=B6=E4=B8=8D=E4=B8=80=E5=AE=9A=E4=BB=A3=E8=A1=A8=E6=9C=AC=E5=85=AC=E5= =8F=B8=E3=80=82
Discl= aimer: This email is intended to be read only by the designated recipient o= f the document and has high confidentiality requirements. Anyone else is pr= ohibited from using, opening, copying or forwarding any of the contents ins= ide. If this email was sent to you by mistake, please contact the sender of= the email and delete this file immediately. Confidentiality and legal priv= ileges are not waived or lost by misdirected emails. Any views or opinions = expressed in the email are those of the author and do not necessarily repre= sent those of the Company.

--d5e97d192149064169ec60aea4a82b424e1b1c67836fec0bce197e8cbfac--