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 A151AC433F5 for ; Fri, 8 Apr 2022 02:10:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D0566B0072; Thu, 7 Apr 2022 22:10:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17FE26B0074; Thu, 7 Apr 2022 22:10:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 020928D0001; Thu, 7 Apr 2022 22:10:32 -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 E829C6B0072 for ; Thu, 7 Apr 2022 22:10:32 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BE04D845 for ; Fri, 8 Apr 2022 02:10:32 +0000 (UTC) X-FDA: 79332082704.16.4DD8303 Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) by imf25.hostedemail.com (Postfix) with ESMTP id 4F586A0005 for ; Fri, 8 Apr 2022 02:10:32 +0000 (UTC) Received: by mail-il1-f170.google.com with SMTP id r11so5586025ila.1 for ; Thu, 07 Apr 2022 19:10:32 -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=3zLo2uZAPFPb1a10/oiW+kNzLrd/tjhqt8zswWgEmmM=; b=RYo/qKEMhFXkj4EEEZGvJ6VFDZ+tSforE2IzUpicHlQ/MFAhXALefpKrPRB75mPtt+ LwAN/p4WQS8oGGtRmuO+G5WEcMOa1EAvFqiDhlC7lh1l4ndUmWgIpMSACdklWU7vHuJ3 bW+C65ucZLINuYcSBx07IA/fu5Txan3nuxAWjN+WLEs28JeBv3l7zgkDIyJWAHW6KN0i sdNZlbScPlrCV3G2u6yxXSZIi76DYmQM/NS2jmaCbCW5Q3K6BeBfnbtcU4hPI8vJzo/J R7jTf4zbZywtg+3GWrThOvSHBeJS30G1EO4VjtBChGE0fe2KHRnkUlzLjc/IABN0jZxt 6xOA== 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=3zLo2uZAPFPb1a10/oiW+kNzLrd/tjhqt8zswWgEmmM=; b=5HQr8m1q77ZJ3iJ4X98xUOMKwsSOmzmY6FZhRQio/Da4DFfq0Y5Il0BhukSHa184yJ rMDqlT2gK2cWTcRqfrD2pj9NYo0SoKMr9v2FpKOzNuxuVxYSikPAzWLJmJNvEOxjlpIT Jtr2tEeQ9cizgfGLQGUqqvn9CZPnwCS7kZNuMLqSou6/xImXjgX/fBCJutnLVyo+4ysC Ltwnvo/dQRRIQbodExFNHX44+BDEsno0NTTu7DtiwxfOF3rc3LWBzCt+jxKIKwyDLf31 y2EMBSsfuUOHa2AXzcOXN5jZtlSE9unaYFMmGsKR2BRucx8PHCWtiVFRRUqk/oR/wyd/ yOKQ== X-Gm-Message-State: AOAM531aVOya16Jf4qWWuVyG49nyJJWP9HpgFfV2RJndRYx/8tiyb7rS 5X/jeHAwhvg6dCwpcP3mcXDnhDv0GG/qC2ZKAr73Hg== X-Google-Smtp-Source: ABdhPJzywFSFz4PYO+zLQREwaiNdmfPXBeHr0ksmWhzLo32ltQANJedCo3Fi6YRF+TuO6wKPeYFJE6Q3/rK52iGg5U8= X-Received: by 2002:a92:ca45:0:b0:2ca:810e:7855 with SMTP id q5-20020a92ca45000000b002ca810e7855mr1672675ilo.303.1649383831471; Thu, 07 Apr 2022 19:10:31 -0700 (PDT) MIME-Version: 1.0 References: <20220331084151.2600229-1-yosryahmed@google.com> <87y20nzyw4.fsf@yhuang6-desk2.ccr.corp.intel.com> <87o81fujdc.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkxfudrk.fsf@yhuang6-desk2.ccr.corp.intel.com> <215bd7332aee0ed1092bad4d826a42854ebfd04a.camel@linux.intel.com> In-Reply-To: From: Wei Xu Date: Thu, 7 Apr 2022 19:10:20 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface To: Tim Chen Cc: "Huang, Ying" , Michal Hocko , Yosry Ahmed , Johannes Weiner , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , Cgroups , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: 6ajwo1t6xgs5dy8qcj7q955cj8och6bq Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="RYo/qKEM"; spf=pass (imf25.hostedemail.com: domain of weixugc@google.com designates 209.85.166.170 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4F586A0005 X-HE-Tag: 1649383832-274957 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 Thu, Apr 7, 2022 at 4:11 PM Tim Chen wrote: > > On Thu, 2022-04-07 at 15:12 -0700, Wei Xu wrote: > > > > > (resending in plain-text, sorry). > > > > memory.demote can work with any level of memory tiers if a nodemask > > argument (or a tier argument if there is a more-explicitly defined, > > userspace visible tiering representation) is provided. The semantics > > can be to demote X bytes from these nodes to their next tier. > > > > We do need some kind of userspace visible tiering representation. > Will be nice if I can tell the memory type, nodemask of nodes in tier Y with > > cat memory.tier_Y > > > > memory_dram/memory_pmem assumes the hardware for a particular memory > > tier, which is undesirable. For example, it is entirely possible that > > a slow memory tier is implemented by a lower-cost/lower-performance > > DDR device connected via CXL.mem, not by PMEM. It is better for this > > interface to speak in either the NUMA node abstraction or a new tier > > abstraction. > > Just from the perspective of memory.reclaim and memory.demote, I think > they could work with nodemask. For ease of management, > some kind of abstraction of tier information like nodemask, memory type > and expected performance should be readily accessible by user space. > I agree. The tier information should be provided at the system level. One suggestion is to have a new directory "/sys/devices/system/tier/" for tiers, e.g.: /sys/devices/system/tier/tier0/memlist: all memory nodes in tier 0. /sys/devices/system/tier/tier1/memlist: all memory nodes in tier 1. We can discuss this tier representation in a new thread. > Tim > > > > > It is also desirable to make this interface stateless, i.e. not to > > require the setting of memory_dram.reclaim_policy. Any policy can be > > specified as arguments to the request itself and should only affect > > that particular request. > > > > Wei >