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 63E39C433EF for ; Wed, 23 Feb 2022 09:36:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E02AC8D0002; Wed, 23 Feb 2022 04:36:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D8A928D0001; Wed, 23 Feb 2022 04:36:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C05058D0002; Wed, 23 Feb 2022 04:36:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id AB4618D0001 for ; Wed, 23 Feb 2022 04:36:26 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5A4B2181CB2D6 for ; Wed, 23 Feb 2022 09:36:26 +0000 (UTC) X-FDA: 79173539172.12.C1E1BCE Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by imf01.hostedemail.com (Postfix) with ESMTP id CB9E840004 for ; Wed, 23 Feb 2022 09:36:25 +0000 (UTC) Received: by mail-vs1-f50.google.com with SMTP id e5so2429732vsg.12 for ; Wed, 23 Feb 2022 01:36:25 -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=RNctXvz/+pBy9XAX0EqBi4IREn0H0T0ytHG6ULPDoI0=; b=V3LuRwEpxHob6IJLmsHbuhIouyLQNrSHcNT4Snuspt5KDa5sThyfL2rrzDDYtjjzBa K9IO34tFfrQD5KR9tgEfdY6KkjuUTZfC6TSAWolAfHbVKCZ0l+jFZMRE6ZcGxff71UY2 vvBhV5Ji9qT2q145R46bknnHaiSo21b1UU2GyBnXm//3H7jko5nnzW00cwOW+Q/Cvq9Y Ol1VIZkRuHYq/9moH6ihYLZt9xQzvhkErQNAfQ0nOyzLf+0qRkPXD/UPZ8NBff8WWLUV XsGzsdFcnAufwM56SI1jh4ipBUd3Yxvv+hlUpdktOcDmn9L9UEZ4yL7ultE9dL7sCjdI CiNA== 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=RNctXvz/+pBy9XAX0EqBi4IREn0H0T0ytHG6ULPDoI0=; b=JK9YahEEfQ7Vc8a0F4CUKlnUynDw5+zoiK1xg7dTzFkOvb6R2GAomxKs6ZrxzAyDl9 7e2+eAi3tWnwib4Ug2c13qzbVr3SfAZiBSeZKI7kt5h5rW6ZlcM78RgesBmqmwiCuw8+ Hv87pas3JxXqI3xg1WF6YmKU9kjbr6ydqeOEuK3ECz7WPfVENzT+5/xQUp0FDjxDOiQX BlC0S/Db4fZwWUldsfRJFCACTOMzBVx1ZBp7+HkwDinScOv6QD3v68iK1Sff3SP/a+wN OEgXNMz5gBWRr6XKYxObVygjec2Yx/H7sMz0dwbysahZZ6KrKr1d3zdyZQftv7/IgQHl C7jQ== X-Gm-Message-State: AOAM533AfyX1yewx8VupPVcGaFBDG0p8h10fS+mUYMpqNOXspNit0P1J 36aTyd32jN1rV1z+zLvJSTvF0A/g13q5LaI24h/O5g== X-Google-Smtp-Source: ABdhPJwrN8fS2vL8pC+XpnMNYgxdYuOBZM8HK8roIA0KECuRJmupbXZoBV8Bw2+nj8jF+3c68XJb462SZUbdaFzsQfQ= X-Received: by 2002:a05:6102:3a06:b0:31b:d9c6:c169 with SMTP id b6-20020a0561023a0600b0031bd9c6c169mr11510124vsu.22.1645608984949; Wed, 23 Feb 2022 01:36:24 -0800 (PST) MIME-Version: 1.0 References: <20220208081902.3550911-1-yuzhao@google.com> <20220208081902.3550911-6-yuzhao@google.com> <87bkyy56nv.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87bkyy56nv.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Yu Zhao Date: Wed, 23 Feb 2022 02:36:13 -0700 Message-ID: Subject: Re: [PATCH v7 05/12] mm: multigenerational LRU: minimal implementation To: "Huang, Ying" Cc: Andrew Morton , Johannes Weiner , Mel Gorman , Michal Hocko , Andi Kleen , Aneesh Kumar , Barry Song <21cnbao@gmail.com>, 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 , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Linux-MM , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , 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: CB9E840004 X-Stat-Signature: nuu495p81aba8pbqbs4kp7howuf1gy3f Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=V3LuRwEp; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1645608985-187143 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 Wed, Feb 23, 2022 at 1:28 AM Huang, Ying wrote: > > Hi, Yu, > > Yu Zhao writes: > > > To avoid confusions, the terms "promotion" and "demotion" will be > > applied to the multigenerational LRU, as a new convention; the terms > > "activation" and "deactivation" will be applied to the active/inactive > > LRU, as usual. > > In the memory tiering related commits and patchset, for example as follows, > > commit 668e4147d8850df32ca41e28f52c146025ca45c6 > Author: Yang Shi > Date: Thu Sep 2 14:59:19 2021 -0700 > > mm/vmscan: add page demotion counter > > https://lore.kernel.org/linux-mm/20220221084529.1052339-1-ying.huang@intel.com/ > > "demote" and "promote" is used for migrating pages between different > types of memory. Is it better for us to avoid overloading these words > too much to avoid the possible confusion? Given that LRU and migration are usually different contexts, I think we'd be fine, unless we want a third pair of terms. > > +static int get_swappiness(struct mem_cgroup *memcg) > > +{ > > + return mem_cgroup_get_nr_swap_pages(memcg) >= MIN_LRU_BATCH ? > > + mem_cgroup_swappiness(memcg) : 0; > > +} > > After we introduced demotion support in Linux kernel. The anonymous > pages in the fast memory node could be demoted to the slow memory node > via the page reclaiming mechanism as in the following commit. Can you > consider that too? Sure. How do I check whether there is still space on the slow node?