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 7EAFDC433EF for ; Thu, 24 Feb 2022 01:34:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6ECF48D0003; Wed, 23 Feb 2022 20:34:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6732C8D0001; Wed, 23 Feb 2022 20:34:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 514BE8D0003; Wed, 23 Feb 2022 20:34:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 275D08D0001 for ; Wed, 23 Feb 2022 20:34:47 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BB39318128AED for ; Thu, 24 Feb 2022 01:34:46 +0000 (UTC) X-FDA: 79175954172.29.BD13AA9 Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf18.hostedemail.com (Postfix) with ESMTP id 469101C0006 for ; Thu, 24 Feb 2022 01:34:46 +0000 (UTC) Received: by mail-ua1-f41.google.com with SMTP id c23so186291uaq.7 for ; Wed, 23 Feb 2022 17:34:46 -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=DlTEvCMe8gLH8mkJngq0jMMrhF4Rb9J1L2FbOtnoMeA=; b=sjYQXiAaTh8Pan58Dwbpxw8kVwXQt1oAtAF/M0W1jQ6kHv5MlMXbLhguJMlVQsz2mt 4eif8qTqHSAlzgJNMnMyUMVZy0186FJfeZP8a5XgyewuzQB8LgrY2v/VlIIxYnS5Tvw1 ahrvsWzDtvSalYitjQ/o/WowcaihqDCzMk82kA52tuXXN6+6QBx7m2q3ulEvMJ16uYEz V5ZujsVnuN04sVmFL0PQPdCxfh/nwn5+yzc7DL6LoS+q3O+BFjnSOUMS2VOf/ZURdy8K DDwVwm1IctjAuB6SKRa1QT3xdSHHJFY0rf7QFg88fopcFzkRII9LEpXSGdwirgd0ndLd SQ0w== 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=DlTEvCMe8gLH8mkJngq0jMMrhF4Rb9J1L2FbOtnoMeA=; b=Fe6dTc/YQeAV8vKjGoe7xEpPCI2omSxYxRtzx7G8oLcCOzHNzpZnhCRRMS9Jif7M9L hR5gB/GqZIZguTy1/81IZ0hEHEX6mj7pfaleU+ZKCKb7Vz82EuVdX97zFG5zZk3DOFMT EZSWeG1Q+pD43Af1SzcJYtO3ZwXOqapsiF1lKcaesknMrHp+Vwm8w/yDLpfjH4Et3vUA S32qR4QO94E5oYscazExqulTzWCkKZHAOouUFm0mAEGx/NOHR5ZsRJ42qd9DpTBjaSfc aqmYzYIspPXtc2uZmfipk+YzHmwCbjYO6cErr8ee1N9b5jl+1CE+r4VPWe3+STOtRHUn JYqQ== X-Gm-Message-State: AOAM533/+e1Dmld1LD/gsG1LHuxSg+MFT9Mc47bj95DTM0Fqfw/kG6n5 GKsWdOTBnp223r+uh/3NP5VOquG29u16erZOAtLJ/w== X-Google-Smtp-Source: ABdhPJxBaf8RnByOCleoWZEZPun+AOvuwypSAyh6/fwhiM94QTJdh8bQ3/HbbFgUPiAM6IdBkr8T8WRot1ZydwqPvVI= X-Received: by 2002:ab0:2111:0:b0:341:8339:51b4 with SMTP id d17-20020ab02111000000b00341833951b4mr162619ual.76.1645666485123; Wed, 23 Feb 2022 17:34:45 -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> <87y2213wrl.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87y2213wrl.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Yu Zhao Date: Wed, 23 Feb 2022 18:34:33 -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-Stat-Signature: gc9cx454566tokn45u8w3p6jcswo7jhp X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=sjYQXiAa; spf=pass (imf18.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 469101C0006 X-HE-Tag: 1645666486-674807 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 5:59 PM Huang, Ying wrote: > > Yu Zhao writes: > > > 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. > > This is true before memory tiering is introduced. In systems with > multiple types memory (called memory tiering), LRU is used to identify > pages to be migrated to the slow memory node. Please take a look at > can_demote(), which is called in shrink_page_list(). This sounds clearly two contexts to me. Promotion/demotion (move between generations) while pages are on LRU; or promotion/demotion (migration between nodes) after pages are taken off LRU. Note that promotion/demotion are not used in function names. They are used to describe how MGLRU works, in comparison with the active/inactive LRU. Memory tiering is not within this context. > >> > +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? > > You can always check the watermark of the slow node. But now, we > actually don't check that (as in demote_page_list()), instead we will > wake up kswapd of the slow node. The intended behavior is something > like, > > DRAM -> PMEM -> disk I'll look into this later -- for now, it's a low priority because there isn't much demand. I'll bump it up if anybody is interested in giving it a try. Meanwhile, please feel free to cook up something if you are interested.