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 E3861C433EF for ; Fri, 15 Apr 2022 09:28:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C35A6B0071; Fri, 15 Apr 2022 05:28:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 04B836B0073; Fri, 15 Apr 2022 05:28:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2FB76B0074; Fri, 15 Apr 2022 05:28:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id D32806B0071 for ; Fri, 15 Apr 2022 05:28:08 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 63DB78249980 for ; Fri, 15 Apr 2022 09:28:08 +0000 (UTC) X-FDA: 79358587056.31.1665A8F Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf01.hostedemail.com (Postfix) with ESMTP id E6DF64000A for ; Fri, 15 Apr 2022 09:28:06 +0000 (UTC) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KfrZg1drlz1HBsy; Fri, 15 Apr 2022 17:27:23 +0800 (CST) Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 15 Apr 2022 17:28:01 +0800 Received: from [10.174.178.178] (10.174.178.178) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 15 Apr 2022 17:27:59 +0800 Message-ID: Date: Fri, 15 Apr 2022 17:27:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Subject: Re: [PATCH v10 06/14] mm: multi-gen LRU: minimal implementation To: Yu Zhao CC: Stephen Rothwell , , Andi Kleen , Andrew Morton , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, Catalin Marinas , Dave Hansen , "Hillf Danton" , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Linus Torvalds , "Matthew Wilcox" , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , , , , , , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=c3=a4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-7-yuzhao@google.com> <71af92d2-0777-c318-67fb-8f7d52c800bb@huawei.com> <4c416f09-5304-07fd-cb53-5c9c8c75f6fa@huawei.com> <9e3ca922-1448-2eb1-b056-218236e7c72f@huawei.com> From: Chen Wandun In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.178.178] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500002.china.huawei.com (7.185.36.229) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E6DF64000A X-Stat-Signature: i3q7nswr5wuuy9nmi5rfi8ej5i3p41ez Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of chenwandun@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=chenwandun@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1650014886-450000 Content-Transfer-Encoding: quoted-printable 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: =E5=9C=A8 2022/4/15 14:44, Yu Zhao =E5=86=99=E9=81=93: > On Fri, Apr 15, 2022 at 02:31:37PM +0800, Chen Wandun wrote: >> >> =E5=9C=A8 2022/4/15 13:25, Yu Zhao =E5=86=99=E9=81=93: >>> On Fri, Apr 15, 2022 at 10:23:18AM +0800, Chen Wandun wrote: >>>> =E5=9C=A8 2022/4/15 4:53, Yu Zhao =E5=86=99=E9=81=93: >>>>> On Thu, Apr 14, 2022 at 07:47:54PM +0800, Chen Wandun wrote: >>>>>> On 2022/4/7 11:15, Yu Zhao wrote: >>>>>>> +static void inc_min_seq(struct lruvec *lruvec) >>>>>>> +{ >>>>>>> + int type; >>>>>>> + struct lru_gen_struct *lrugen =3D &lruvec->lrugen; >>>>>>> + >>>>>>> + VM_BUG_ON(!seq_is_valid(lruvec)); >>>>>>> + >>>>>>> + for (type =3D 0; type < ANON_AND_FILE; type++) { >>>>>>> + if (get_nr_gens(lruvec, type) !=3D MAX_NR_GENS) >>>>>>> + continue; >>>>>> I'm confused about relation between aging and LRU list operation. >>>>>> >>>>>> In function inc_max_seq,=C2=A0 both min_seq and max_seq will incre= ase=EF=BC=8C >>>>>> the lrugen->lists[] indexed by lru_gen_from_seq(max_seq + 1) may >>>>>> be non-empty? >>>>> Yes. >>>>> >>>>>> for example, >>>>>> before inc_max_seq: >>>>>> min_seq =3D=3D 0, lrugen->lists[0][type][zone] >>>>>> max_seq =3D=3D3, lrugen->lists[3][type][zone] >>>>>> >>>>>> after inc_max_seq: >>>>>> min_seq =3D=3D1, lrugen->lists[1][type][zone] >>>>>> max_seq =3D=3D4, lrugen->lists[0][type][zone] >>>>>> >>>>>> If lrugen->lists[0][type][zone] is not empty before inc_max_seq an= d it is >>>>>> the most inactive list=EF=BC=8Chowever lurgen->lists[0][type][zone= ] will become >>>>>> the most active list after inc_max_seq. >>>>> Correct. >>>>> >>>>>> So,=C2=A0 in this place, >>>>>> >>>>>> if (get_nr_gens(lruvec, type) !=3D MAX_NR_GENS) >>>>>> continue; >>>>>> >>>>>> should change to >>>>>> >>>>>> if (get_nr_gens(lruvec, type) =3D=3D MAX_NR_GENS) >>>>>> continue; >>>>> No, because max/min_seq will overlap if we do so. >>>>> >>>>> lrugen->lists[max_seq+1] can only be non-empty for anon LRU, for a >>>>> couple of reasons: >>>>> 1. We can't swap at all. >>>>> 2. Swapping is constrained, e.g., swapfile is full. >>>>> >>>>> Both cases are similar to a producer (the aging) overrunning a >>>>> consumer (the eviction). We used to handle them, but I simplified t= he >>>>> code because I don't feel they are worth handling [1]. >>>> Can lrugen->lists[max_seq+1]=C2=A0 also be non-empty for file LRU=EF= =BC=9F >>> On reclaim path, no. But it can be forced to do so via debugfs. >>> >>>> such as in dont reclaim mapped file page case(isolation will fail). >>> You mean may_unmap=3Dfalse? Pages stays in the same generation if >>> isolation fails. So lrugen->lists[min_seq] won't be empty in this >>> case. >>> >>>> If so, after aging, eviction will reclaim memory start from >>>> lrugen->lists[min_seq+1], but some oldest file page still >>>> remain in lrugen->lists[max_seq+1]. >>>> >>>> sort_folio can help to put misplaced pages to the right >>>> LRU list, but in this case, it does't help, because sort_folio >>>> only sort lrugen->lists[min_seq+1]. >>> On reclaim path, inc_max_seq() is only called when need_aging=3Dtrue, >>> and this guarantees max_seq-min_seq[LRU_GEN_FILE]+1 < MAX_NR_GENS. >> yes, I think so, but I did't find the logical in function get_nr_evict= able, >> or am I missing something >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (min_seq[LRU_GEN_FILE] = + MIN_NR_GENS > max_seq) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 *need_aging =3D true; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else if (min_seq[LRU_GEN_F= ILE] + MIN_NR_GENS < max_seq) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 *need_aging =3D false; > This branch. > > And the following is also relavent: > > static int __init init_lru_gen(void) > { > BUILD_BUG_ON(MIN_NR_GENS + 1 >=3D MAX_NR_GENS); Got it, many thanks. Wandun > .