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 E4321C433EF for ; Fri, 15 Apr 2022 20:19:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75B506B0072; Fri, 15 Apr 2022 16:19:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E50B6B0073; Fri, 15 Apr 2022 16:19:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 538516B0075; Fri, 15 Apr 2022 16:19:15 -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 3D5F66B0073 for ; Fri, 15 Apr 2022 16:19:15 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0A7D32096C for ; Fri, 15 Apr 2022 20:19:15 +0000 (UTC) X-FDA: 79360227870.08.59C4948 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf15.hostedemail.com (Postfix) with ESMTP id 88B3DA0004 for ; Fri, 15 Apr 2022 20:19:14 +0000 (UTC) Received: by mail-vk1-f178.google.com with SMTP id i27so3923829vkr.5 for ; Fri, 15 Apr 2022 13:19:14 -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=RL4h06AiN/8w2o0+WiSAeDo+mIxH1CqmEN55coz0ZRI=; b=cG7AXdVOmojd7MPJeyvdAKpKNSrCsdc+0C+jBZpP/l0cPfjWbDkpXc3uKsnXjHbZV9 qR7pzwGxqiqamTg07BI4QpeQJkph+ny9gAUXN6/7mo8ghhN+OIANuDNLKjziKKYdyzyJ El2R76h+olnjDnbnNKUeCK0M3JWu48ALCpHFw7W/rtZut0Gl0juIqxIeEwZ9yWG+EZC3 TOKHl8t1j7iotttaFvZUE2R9Je9NTb/0fRabz22i0mg7OujgPkQryjsCzYOwAskzqem+ OHTlmpmBZVh9rADP00Nu6D0ZtshSsA0skqt2BD2DVNk9Ymqle9R1FG8+H/pL8yJzoA0r f8FQ== 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=RL4h06AiN/8w2o0+WiSAeDo+mIxH1CqmEN55coz0ZRI=; b=MlAyZ3wJsJkWTnCaxgBPumdesRhohCkV6LfqetS/6TOHwn90kM2NdsbOyOrNaiY7Zr qfb8XegF3pa8dpvDL4NFbis6WclE9uHheyXLPQi2wsj0VwSdbyqGU76utL0DFKOjllt4 cVnmbcsRGeEhAzXXgPkyVgHdA9ve/xZtkp95H9XJW0hsXpS9+5kPVxvrTKCF37VvoXwQ H4KIXCREL/lRwlGjjkECzPC4atiYLHpKf3Uu1oqKwqg6DGxNAeeXOnedOhPiSQjCKslA 5qKdwPpdJTa6Wy3gZPtyinIqu4dcGUac5aMmhtR7DIg9GDuRUDCPIW/xFzmoZKmrEWKI 2dtg== X-Gm-Message-State: AOAM531djHx1j5MNoMM/UW1LVRpxuumNXk15vyH28Rp4Tj2AvTDt1jf3 Daa5FTACjswo7fMHKfwbI+SFfbxZytKK002ymqURJQ== X-Google-Smtp-Source: ABdhPJyixbc34eO6iyu54XQyh9mZgb+tRH7Zy9C+wfiLqmqg/wY+fuq9KDoFF7OSWdQsq/iJaXoxUlUwz8RQNa0Yfso= X-Received: by 2002:a1f:32cf:0:b0:345:cdce:5dcd with SMTP id y198-20020a1f32cf000000b00345cdce5dcdmr200317vky.14.1650053953620; Fri, 15 Apr 2022 13:19:13 -0700 (PDT) MIME-Version: 1.0 References: <20220407031525.2368067-1-yuzhao@google.com> <20220407031525.2368067-7-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Fri, 15 Apr 2022 14:18:37 -0600 Message-ID: Subject: Re: [PATCH v10 06/14] mm: multi-gen LRU: minimal implementation To: Barry Song <21cnbao@gmail.com> 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" X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 88B3DA0004 X-Stat-Signature: bqsts6y98h733z6cgwto3pk6wz3fes1j Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cG7AXdVO; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-HE-Tag: 1650053954-567670 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 4:26 AM Barry Song <21cnbao@gmail.com> wrote: > > 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(); This looks good to me. I've queued it for the next version. Thanks.