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 2B0ADC433F5 for ; Fri, 11 Mar 2022 23:45:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D06A8D0002; Fri, 11 Mar 2022 18:45:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 858B98D0001; Fri, 11 Mar 2022 18:45:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 683EF8D0002; Fri, 11 Mar 2022 18:45:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id 52D598D0001 for ; Fri, 11 Mar 2022 18:45:18 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F283C181D2075 for ; Fri, 11 Mar 2022 23:45:17 +0000 (UTC) X-FDA: 79233739074.25.3ABFE9F Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by imf21.hostedemail.com (Postfix) with ESMTP id 8EAB41C0027 for ; Fri, 11 Mar 2022 23:45:17 +0000 (UTC) Received: by mail-vs1-f42.google.com with SMTP id u124so11141691vsb.10 for ; Fri, 11 Mar 2022 15:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jgWt/h1KdiygO0MXrJh7m5UOZKMB2VItBU/y6w5jdRk=; b=oZytWIDQPcCDRDIoQChqrlmhIaD7llu9P5DEu+KS08AIzPIgLCPKKBsZwyF5mi1Pc4 HXZCyOe3GkMnCEF/VHXh49dszLjisjb1WNh4B1X5fMVv4jCDWLEKJ7v9CwjbYUjSm6xt 4hq89LSLAzFz79dWnRWkQ6TCQPCALfFEDTmXwI5Mmrmg3xi/j5/UYeU4FVFXslNem1ZT gmJC8ftfUIis2szN1Q/4wywZpcNI/hyLDDyB6ubDBpasB/vWMQuEdlOddyRN/oOxxWaM 0onT8FS0mikrQJQgRDh+oTQPV5A8N73AorqNYxSEGOdbRGq75oAWoPwfmACGFTSVUqgA wklA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jgWt/h1KdiygO0MXrJh7m5UOZKMB2VItBU/y6w5jdRk=; b=IJRoZ5pa6W+OxghA8fY94uRds0o+YZIyYLfc8TlovOPZf0NidA3nYWxAce2NMJY1Ao OV/CUQoqShJ5yf0kWL7MifRbC3q+2PZCvdHv604LTJ00ryCcCSlbXgUlq6QBuCrhVvBz kZAQepAVy03ynKdDktDfBIPmxDi87TXQSNI19jZLNWxp/WvDO6L9qCacnCJvrUpkqQYO /jT6TLVvkQb3CR075/ODS2Ilj63BGcdfTv+b9j0qfO4/qCga1Dcfk3TB/aZpQRELXGRN pq6wuHlPuJ2gEDYP3ksqBw3IKGbKRRS3zO4sn4wNrj/TOJAYjrIlujzYXwXZJpI9gL2F 3JHg== X-Gm-Message-State: AOAM532RbIe+lTXWc/ZCJs1WVRkMu1xiBaOGYUo1a4Ak+2Zwr73glhXU nK/0zd+Jt2cGcw8jB8KGwPSnt9BbqqIyFmkKZxNFhg== X-Google-Smtp-Source: ABdhPJzo48Uus6VFTpGZvjATe6Iht5+Z3+GWkPxJhUQ3VuQempIIQjYA0aVJsViX8+/2Mk2XMNiUidRQDZfkYAxEtJU= X-Received: by 2002:a05:6102:3a06:b0:31b:d9c6:c169 with SMTP id b6-20020a0561023a0600b0031bd9c6c169mr5989160vsu.22.1647042316582; Fri, 11 Mar 2022 15:45:16 -0800 (PST) MIME-Version: 1.0 References: <20220208081902.3550911-1-yuzhao@google.com> <20220208081902.3550911-5-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Fri, 11 Mar 2022 16:45:04 -0700 Message-ID: Subject: Re: [PATCH v7 04/12] mm: multigenerational LRU: groundwork To: Barry Song <21cnbao@gmail.com> Cc: Johannes Weiner , Andrew Morton , Mel Gorman , Michal Hocko , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Jonathan Corbet , Linus Torvalds , Matthew Wilcox , Michael Larabel , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , LAK , Linux Doc Mailing List , LKML , Linux-MM , Kernel Page Reclaim v2 , x86 , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8EAB41C0027 X-Stat-Signature: 5rdgsjdmft4sk6c1biffbx71zbsmphu1 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=oZytWIDQ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1647042317-549368 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: On Fri, Mar 11, 2022 at 3:16 AM Barry Song <21cnbao@gmail.com> wrote: > > On Tue, Feb 15, 2022 at 10:43 PM Yu Zhao wrote: > > > > On Thu, Feb 10, 2022 at 03:41:57PM -0500, Johannes Weiner wrote: > > > > Thanks for reviewing. > > > > > > +static inline bool lru_gen_is_active(struct lruvec *lruvec, int gen) > > > > +{ > > > > + unsigned long max_seq = lruvec->lrugen.max_seq; > > > > + > > > > + VM_BUG_ON(gen >= MAX_NR_GENS); > > > > + > > > > + /* see the comment on MIN_NR_GENS */ > > > > + return gen == lru_gen_from_seq(max_seq) || gen == lru_gen_from_seq(max_seq - 1); > > > > +} > > > > > > I'm still reading the series, so correct me if I'm wrong: the "active" > > > set is split into two generations for the sole purpose of the > > > second-chance policy for fresh faults, right? > > > > To be precise, the active/inactive notion on top of generations is > > just for ABI compatibility, e.g., the counters in /proc/vmstat. > > Otherwise, this function wouldn't be needed. > > Hi Yu, > I am still quite confused as i am seeing both active/inactive and lru_gen. > eg: > > root@ubuntu:~# cat /proc/vmstat | grep active > nr_zone_inactive_anon 22797 > nr_zone_active_anon 578405 > nr_zone_inactive_file 0 > nr_zone_active_file 4156 > nr_inactive_anon 22800 > nr_active_anon 578574 > nr_inactive_file 0 > nr_active_file 4215 Yes, this is expected. We have to maintain the ABI, i.e., the *_active/inactive_* counters. > and: > > root@ubuntu:~# cat /sys//kernel/debug/lru_gen > > ... > memcg 36 /user.slice/user-0.slice/user@0.service > node 0 > 20 18820 22 0 > 21 7452 0 0 > 22 7448 0 0 > memcg 33 /user.slice/user-0.slice/user@0.service/app.slice > node 0 > 0 2171452 0 0 > 1 2171452 0 0 > 2 2171452 0 0 > 3 2171452 0 0 > memcg 37 /user.slice/user-0.slice/session-1.scope > node 0 > 42 51804 102127 0 > 43 18840 275622 0 > 44 16104 216805 1 > > Does it mean one page could be in both one of the generations and one > of the active/inactive lists? In terms of the data structure, evictable pages are either on lruvec->lists or lrugen->lists. > Do we have some mapping relationship between active/inactive lists > with generations? For the counters, yes -- pages in max_seq and max_seq-1 are counted as active, and the rest are inactive. > We used to put a faulted file page in inactive, if we access it a > second time, it can be promoted > to active. then in recent years, we have also applied this to anon > pages while kernel adds > workingset protection for anon pages. so basically both anon and file > pages go into the inactive > list for the 1st time, if we access it for the second time, they go to > the active list. if we don't access > it any more, they are likely to be reclaimed as they are inactive. > we do have some special fastpath for code section, executable file > pages are kept on active list > as long as they are accessed. Yes. > so all of the above concerns are actually not that correct? They are valid concerns but I don't know any popular workloads that care about them.