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 7319BC433EF for ; Fri, 8 Apr 2022 03:08:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED72C8D0001; Thu, 7 Apr 2022 23:08:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5EF36B0075; Thu, 7 Apr 2022 23:08:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8C08D0001; Thu, 7 Apr 2022 23:08:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id B92246B0074 for ; Thu, 7 Apr 2022 23:08:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 70A311828A443 for ; Fri, 8 Apr 2022 03:08:56 +0000 (UTC) X-FDA: 79332229872.29.A679A56 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 56DC1140002 for ; Fri, 8 Apr 2022 03:08:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649387335; x=1680923335; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=mip+/VJYm0x9QxlXtQ8hn3QtLV04GsE06YGBmuPIRI4=; b=HAj6ps0oypwmCIe8RO8AyJieBVHsvvNq7W76rm/8/J/pndCRVzy4wS75 UWbv9wwxTt7bgdDzTJTSdwVppJgrfJKkf0ovY1uvl6cb2cuSEwGc8zj/4 Gx3Sq8CUETGhNaH6SJbrDnLCxbEg+dap/bPfFpjkOGCiWKzkWekJw2569 oT2ocIh/qMzA6qA+TU1nMfSp+3sP9LAVhCFHiYogkcnwVe1aXk6IEuUpF 9vI09daxcEpT5q/C35e8RVOkhxhjLpEO2pPfL2c6NYOjxw52KQiT+TlhZ 1mhWKW7na0muEx+8olDLAYkaE1FR0O8gm6B3pywi/ROl4NpNpV/WRw2PJ Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="347936836" X-IronPort-AV: E=Sophos;i="5.90,243,1643702400"; d="scan'208";a="347936836" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 20:08:35 -0700 X-IronPort-AV: E=Sophos;i="5.90,243,1643702400"; d="scan'208";a="723226573" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 20:08:30 -0700 From: "Huang, Ying" To: Wei Xu Cc: Tim Chen , 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 Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface 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> Date: Fri, 08 Apr 2022 11:08:28 +0800 In-Reply-To: (Wei Xu's message of "Thu, 7 Apr 2022 19:10:20 -0700") Message-ID: <87y20gtgpf.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=HAj6ps0o; spf=none (imf26.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 56DC1140002 X-Stat-Signature: 3eor7wpaug3ggykph1ybpxifbjhh41ct X-HE-Tag: 1649387335-111552 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: Wei Xu writes: > 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. I think that it may be sufficient to make tier an attribute of "node". Some thing like, /sys/devices/system/node/nodeX/memory_tier Best Regards, Huang, Ying > 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 >>