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 06011C433F5 for ; Sat, 12 Mar 2022 10:37:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30CBD8D0002; Sat, 12 Mar 2022 05:37:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 294A88D0001; Sat, 12 Mar 2022 05:37:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 110178D0002; Sat, 12 Mar 2022 05:37:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id EF7698D0001 for ; Sat, 12 Mar 2022 05:37:47 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A3E8B241C9 for ; Sat, 12 Mar 2022 10:37:47 +0000 (UTC) X-FDA: 79235383374.10.D6DE81B Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf12.hostedemail.com (Postfix) with ESMTP id 30F5A4001E for ; Sat, 12 Mar 2022 10:37:47 +0000 (UTC) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2dbd97f9bfcso118314137b3.9 for ; Sat, 12 Mar 2022 02:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M1bd0GMikTEkuWaHRWz8cZoWjC5BnF6mI6Xq7ESbeM0=; b=D5OAwynWbOtXSOPxCNmXI21wxYKK8tWl5p9WpcvhaONPNhxVPy6WSAHKu8jz0JjHoL I3It/QS1ORaXhjqTkIwzmV4SQr/ckkJ8LARMq+c7lVonj3nEsSLExLmSyJSp6LPHvJ/J 5l8Mh7bTmzVqHbUEtVpGgm7LNmxIN3kH99B3qif7NNptdxElHmEAp94HbOuPeYIecqWY /84AzZ9sR8BknA5s7dWlz1/jXVWHVOSh+RsADR8/Ic1oxQypGsgJ/uBKsGiVXYGpSvSF eD1lyMR3eMkGER8PgKH2mCAPXDkAlsYudANaLxiw0HaXMwYZPpvGu1wmAwAB/P3QV9GN 2OVQ== 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=M1bd0GMikTEkuWaHRWz8cZoWjC5BnF6mI6Xq7ESbeM0=; b=qDSabASZ13sj/1GRMw1nYkOrP/OJW2YwbSRmGJvk73CVJ9Gf8cch+dMQnlFAnGP8Ca 06L5FGOGJPlU9CQ3IbvSi8HZQQFSo3kyFEAeGZfNHTphPq5Bo5BL/yduRJUujf6Z8KZx abEqytTbKxqTUkbc62LCpRa+PsQENsyOPi0fkGHjYc17Zr5NQATrjeWsdlHOyjhfGNAp uOR6YRl+s50IMC8ES5ubFsmkJgJET7kGzS/U9SFnx7qryb56aMui1Mhx3p41pQ8zRCXn l5ag+XTq0leRPMV/Ixf3HU+DMxI75OZjJOsg+ML7jEa8kmIJ9hfwiP0CyIzvvUEWx4zO J3nA== X-Gm-Message-State: AOAM530Qpoh/b6FGZh4fnnCMc4CQeydOkQG2Bhha7cBDpnmZL1nuHOtS RLWEkEdR+8AVHPgg/2Vet0HZEBDa30fwDY4n1Wk= X-Google-Smtp-Source: ABdhPJzg7xAB7h8JW4bHsV019kKs7xGRffKUSBEupdCX+zGWN1izM4TaZn6FHw5ryHhJTcpFCl2QEYhz/1eV8RSpszk= X-Received: by 2002:a81:1658:0:b0:2dc:5e3b:488d with SMTP id 85-20020a811658000000b002dc5e3b488dmr11866621yww.399.1647081466454; Sat, 12 Mar 2022 02:37:46 -0800 (PST) MIME-Version: 1.0 References: <20220208081902.3550911-1-yuzhao@google.com> <20220208081902.3550911-5-yuzhao@google.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 12 Mar 2022 23:37:35 +1300 Message-ID: Subject: Re: [PATCH v7 04/12] mm: multigenerational LRU: groundwork To: Yu Zhao 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-Server: rspam11 X-Rspamd-Queue-Id: 30F5A4001E Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=D5OAwynW; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: owe4y4k9ukwt1e17poknypcuyecp15z7 X-HE-Tag: 1647081467-924688 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 Sat, Mar 12, 2022 at 12:45 PM Yu Zhao wrote: > > 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. Hi Yu, here we can get a workload in Kim's patchset while he added workingset protection for anon pages: https://patchwork.kernel.org/project/linux-mm/cover/1581401993-20041-1-git-send-email-iamjoonsoo.kim@lge.com/ anon pages used to go to active rather than inactive, but kim's patchset moved to use inactive first. then only after the anon page is accessed second time, it can move to active. "In current implementation, newly created or swap-in anonymous page is started on the active list. Growing the active list results in rebalancing active/inactive list so old pages on the active list are demoted to the inactive list. Hence, hot page on the active list isn't protected at all. Following is an example of this situation. Assume that 50 hot pages on active list and system can contain total 100 pages. Numbers denote the number of pages on active/inactive list (active | inactive). (h) stands for hot pages and (uo) stands for used-once pages. 1. 50 hot pages on active list 50(h) | 0 2. workload: 50 newly created (used-once) pages 50(uo) | 50(h) 3. workload: another 50 newly created (used-once) pages 50(uo) | 50(uo), swap-out 50(h) As we can see, hot pages are swapped-out and it would cause swap-in later." Is MGLRU able to avoid the swap-out of the 50 hot pages? since MGLRU is putting faulted pages to the youngest generation directly, do we have the risk mentioned in Kim's patchset? Thanks Barry