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 1173CC433F5 for ; Tue, 22 Mar 2022 00:30:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 487596B0074; Mon, 21 Mar 2022 20:30:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40F5E6B0075; Mon, 21 Mar 2022 20:30:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2631E8D0001; Mon, 21 Mar 2022 20:30:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 105BC6B0074 for ; Mon, 21 Mar 2022 20:30:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AEF528249980 for ; Tue, 22 Mar 2022 00:30:19 +0000 (UTC) X-FDA: 79270140558.17.5EAA746 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf27.hostedemail.com (Postfix) with ESMTP id 10D6240018 for ; Tue, 22 Mar 2022 00:30:18 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id m184so5036242vsm.12 for ; Mon, 21 Mar 2022 17:30:18 -0700 (PDT) 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=zZqXUZvSGoiAU4OWPpv+kWmYsbJWpiQeFt4daxe81ds=; b=hfrCmbEHl2h5Rii7re10yHpXsfBWYOfGCKo+XQHmbiS2ORaNCnijKzF+qeBzW3BQpF fyyM1ZUD/bMfWg5gp9nIKppanhrDqXzd0BiDWLV4odII5vc2bLY4QqqpziOuJ2O1TrJw flhQd3vAAwtgT1Xv8Ojt/JsqvVFijWUgiWh0miJ97JPj/PZDacbcaVTJnJ+7etv/AVCb /mgprhIyrwN2hOE5UMF6b/8I774/2nwphiQzlUB+Lwssicdx9Q+0boWzoygBzkomBf1m M0MRwgVymI1GJRyV7aTF9G1e9F0CjK38bjWTNQmYAksU3FtMFXOstcscKc0OheQ8B1wS VTwQ== 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=zZqXUZvSGoiAU4OWPpv+kWmYsbJWpiQeFt4daxe81ds=; b=4Mke4dtWmcqPcOWuIj+skTIAI/+dB8Ss3mc/JvI8kmrJZGmiYjW6YnzaiFBLVUVRoS UP4wLY/Ayh9zONY4X9kz4Dk8uCcA8PZDRUReXZBqJnVBWmpibxAEd+0z3esbcdMO6B6w XoYwrZiHJ7A4eVtO170E1EyN8ZSuySzb9j7MaY7QT0O1qDm4zaw+8uoc13Rr7PvhYIp1 nTuCyruWr+TiLOsW89FTa4W59/ddu8E6vFgNCrSp6eVVk/E2foklkxTIbhDS8CSm0zfK 3kQN02HrXj/wp12D2ryAKhvoMlubIA0ylLnooigamBpy4mSQcRy/DRGzj020uvPtb8m+ bYuA== X-Gm-Message-State: AOAM531UxxGJIpvxq7aNxpbfk0PF6dmHKD9vfBA8/YzOYEhmApYoh64Q Deaqg3SObEi7Gk+ITvCfl9bjUV1ayy/NJoqbg/92TQ== X-Google-Smtp-Source: ABdhPJzz/wKqvQqJK+JokQegaEl/jW4BCcQKHCuV6sRHJ+7nBGMqKAZzoeJYJwW4PjrsgyHNP+iVv5C2qA0h2jzH8mg= X-Received: by 2002:a05:6102:291f:b0:325:11be:5bf0 with SMTP id cz31-20020a056102291f00b0032511be5bf0mr2955888vsb.41.1647909018098; Mon, 21 Mar 2022 17:30:18 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-7-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Mon, 21 Mar 2022 18:30:06 -0600 Message-ID: Subject: Re: [PATCH v9 06/14] mm: multi-gen LRU: minimal implementation To: Barry Song <21cnbao@gmail.com> Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , 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 , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=hfrCmbEH; spf=pass (imf27.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 10D6240018 X-Stat-Signature: bomqprnsbeat5ogfofrgnr75p9iiroqc X-HE-Tag: 1647909018-53873 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 19, 2022 at 5:15 AM Barry Song <21cnbao@gmail.com> wrote: > > > + unsigned long *min_seq, bool can_swap, bool *need_aging) > > +{ > > + int gen, type, zone; > > + long old = 0; > > + long young = 0; > > + long total = 0; > > + struct lru_gen_struct *lrugen = &lruvec->lrugen; > > + > > + for (type = !can_swap; type < ANON_AND_FILE; type++) { > > + unsigned long seq; > > + > > + for (seq = min_seq[type]; seq <= max_seq; seq++) { > > + long size = 0; > > + > > + gen = lru_gen_from_seq(seq); > > + > > + for (zone = 0; zone < MAX_NR_ZONES; zone++) > > + size += READ_ONCE(lrugen->nr_pages[gen][type][zone]); > > + > > + total += size; > > + if (seq == max_seq) > > + young += size; > > + if (seq + MIN_NR_GENS == max_seq) > > + old += size; > > + } > > + } > > + > > + /* try to spread pages out across MIN_NR_GENS+1 generations */ > > + if (min_seq[LRU_GEN_FILE] + MIN_NR_GENS > max_seq) > > + *need_aging = true; > > + else if (min_seq[LRU_GEN_FILE] + MIN_NR_GENS < max_seq) > > + *need_aging = false; > > + else if (young * MIN_NR_GENS > total) > > + *need_aging = true; > > Could we have some doc here? Will do. > Given MIN_NR_GENS=2 and MAX_NR_GENS=4, > it seems you mean if we have three generations and the youngest pages are more > than 1/2 of the total pages, we need aging? Yes. > > + else if (old * (MIN_NR_GENS + 2) < total) > > + *need_aging = true; > > it seems you mean if the oldest pages are less than 1/4 of the total pages, > we need aging? Yes. > Can we have comments to explain why here? > > your commit message only says " The aging produces young generations. > Given an lruvec, it increments max_seq when max_seq-min_seq+1 > approaches MIN_NR_GENS." it can't explain what the code is doing > here. Fair enough. Approaching MIN_NR_GENS=2 means getting close to it. From the consumer's POV, if it *reaches* 2, the eviction will have to stall, because the two youngest generations are not yet fully aged, i.e., the second chance policy similar to the active/inactive lru. >From the producer's POV, the aging tries to be lazy to reduce the overhead. So ideally, we want 3 generations, which gives a reasonable range [2, 4], hence the first two if's. In addition, we want pages to spread out evenly over these 3 generations, meaning an average 1/3 of total pages for each generation, which gives another reasonable range [1/2, 1/4]. Since the eviction reduces the number of old pages, we only need to check against the lower bound, i.e., 1/4. On the other hand, page (re)faults increase the number of young pages, so in this case, we need to check against the upper bound. I'll include these details in the next spin.