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 86C41C433EF for ; Fri, 15 Apr 2022 10:26:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C41A96B0071; Fri, 15 Apr 2022 06:26:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF1106B0073; Fri, 15 Apr 2022 06:26:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A91EF6B0074; Fri, 15 Apr 2022 06:26:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 977F56B0071 for ; Fri, 15 Apr 2022 06:26:21 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0320A25B61 for ; Fri, 15 Apr 2022 10:26:20 +0000 (UTC) X-FDA: 79358733762.14.662BCA8 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf24.hostedemail.com (Postfix) with ESMTP id 38691180002 for ; Fri, 15 Apr 2022 10:26:20 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id t11so14645249eju.13 for ; Fri, 15 Apr 2022 03:26:19 -0700 (PDT) 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=EtDl/BnBqyaqmvNLPjWYvphBfIcsljxIrWQRv32e4H8=; b=m4qCrQ1uGb3UnhyzgxnHQ29si2Yo2S8ghaU7xMVP0qXgiMhgFKso/9N+uhSQSQqJ1I rQnzVisPwlzhsOsTAEeLSu1ebmPt0n8OtWGYFBl4yu4KJj7kO88co+sLF7Xqgs4m9vmd 04mZCu4QPhFnUG0K8YqqZO7VMY7oBOnNwouYz88ShlAkAVN/s87Co1yL7zVHqJW5TE+R aRIUQSKT81I7MsoeXVvrMRoFYX9Ar3OyUEzrMdbfXafaEb8v7MYciVnZrbYqGFDHWuid 1Msm3+ZKEW9qRjOtin3wVbTJkz9tn7ox5tdE7+13UGfPA0V7vj++3zNz3cca+YADbodu wSYQ== 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=EtDl/BnBqyaqmvNLPjWYvphBfIcsljxIrWQRv32e4H8=; b=04Ex3rk6wN+rYXhdtUu5fsGw3zpdd5yG8ZXEUVWv1AdQae90wI/xSDwO7ssubepWVz 3uFPtTWATLSfzqWi35Lfn9y6Dg8DBy8opoEggeo8OUN8OcEWD6au+k7IzRNUi2bYL6wP 9SyKQno+NrBPPmxe/f0V7mdef/KP9tcsFyvRuFi5/qkGfOHMqhSa34ovBZG7AlgLA5DH DL28v0E1EZ4u/tTQRd/l5kQwCXmdezxIKWT/wthiebuq/9nGB17Z8uth7riY5l2mz0P4 3AcrTzcS+eWKnohbsRc+CDVdA0Ym/4vwb9kkRA/ADJaJchLpJxJLln+Isb6cblH9YJ1i XzsQ== X-Gm-Message-State: AOAM533+CWG8dm53tJpjxA33+u+lArxxtwkgari8c76S9hzQi3ZKUfvP PeMNRI25X70A+rXl0prbOZjUN0bUC1BuZ/pmOKE= X-Google-Smtp-Source: ABdhPJx188kl7Hz4e0/sADxts1l08dfuqnxi4RajAY94xDZT5CAK32+z2N7VLWp7X9SwHSIUbAHO5Ks11HdisEYJGeE= X-Received: by 2002:a17:906:39da:b0:6cf:7f09:a7bc with SMTP id i26-20020a17090639da00b006cf7f09a7bcmr5896450eje.457.1650018378797; Fri, 15 Apr 2022 03:26:18 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-7-yuzhao@google.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 15 Apr 2022 22:26:07 +1200 Message-ID: Subject: Re: [PATCH v10 06/14] mm: multi-gen LRU: minimal implementation To: Yu Zhao Cc: Stephen Rothwell , Linux-MM , Andi Kleen , Andrew Morton , Aneesh Kumar , 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 , LAK , Linux Doc Mailing List , LKML , 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: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m4qCrQ1u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 38691180002 X-Stat-Signature: 4oferituoae8dib89pb9zxymtx5j931n X-HE-Tag: 1650018380-268382 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, Apr 15, 2022 at 8:36 AM Yu Zhao wrote: > > On Thu, Apr 14, 2022 at 06:03:10PM +1200, Barry Song wrote: > > > > On Thu, Apr 7, 2022 at 3:16 PM Yu Zhao wrote: > > > > > > + > > > +static int isolate_folios(struct lruvec *lruvec, struct scan_control *sc, int swappiness, > > > + int *type_scanned, struct list_head *list) > > > +{ > > > + int i; > > > + int type; > > > + int scanned; > > > + int tier = -1; > > > + DEFINE_MIN_SEQ(lruvec); > > > + > > > + VM_BUG_ON(!seq_is_valid(lruvec)); > > > + > > > + /* > > > + * Try to make the obvious choice first. When anon and file are both > > > + * available from the same generation, interpret swappiness 1 as file > > > + * first and 200 as anon first. > > > + */ > > > > Has this changed the ABI of swapiness? > > No. > > > or it is only something > > meaningful for the internal code? > > This is how swappiness is interpreted. > > > if so, can we rename it to > > something else? otherwise, it is quite confusing. > > Feel free to suggest something. > > > it seems 1 is set internally as a magic number here: > > +static void lru_gen_shrink_lruvec(struct lruvec *lruvec, struct > > scan_control *sc) > > +{ > > + ... > > + else if (!cgroup_reclaim(sc) && get_swappiness(lruvec, sc)) > > + swappiness = 1; > > + else > > + swappiness = 0; > > + } > > obviously this swappiness is neither /proc/sys/vm/swappiness nor > > /sys/fs/cgroup/memory//>memory.swappiness, right? > > Right. > > > > @@ -3928,6 +4726,11 @@ static void age_active_anon(struct pglist_data *pgdat, > > > struct mem_cgroup *memcg; > > > struct lruvec *lruvec; > > > > > > + if (lru_gen_enabled()) { > > > + lru_gen_age_node(pgdat, sc); > > > + return; > > > + } > > > > is it really a good place for lru_gen_age_node() since the function > > is named age_active_anon() > > but here you are doing aging for both anon and file pages? > > Yes. > > > obviously > > lru_gen_age_node() is not > > doing "age active anon". > ;> We can rename it if you have something in mind. i wonder if we can directly do: if (lru_gen_enabled()) lru_gen_age_node(pgdat, sc); else age_active_anon(); rather than: /* * Do some background aging of the anon list, to give * pages a chance to be referenced before reclaiming. All * pages are rotated regardless of classzone as this is * about consistent aging. */ age_active_anon() { if (lru_gen_enabled()) return lru_gen_age_node(pgdat, sc); } the comment above makes no sense to lru_gen_age_node(pgdat, sc); another way is that we can add a wrapper for them as below, age_node() { if (lru_gen_enabled()) return lru_gen_age_node(pgdat, sc); age_active_anon(); } Thanks Barry