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 17E73C433EF for ; Thu, 7 Apr 2022 23:11:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41F836B0072; Thu, 7 Apr 2022 19:11:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CDF66B0073; Thu, 7 Apr 2022 19:11:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26F3A6B0074; Thu, 7 Apr 2022 19:11:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 175B76B0072 for ; Thu, 7 Apr 2022 19:11:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B4547183EE7B2 for ; Thu, 7 Apr 2022 23:11:10 +0000 (UTC) X-FDA: 79331630700.30.4204C1F Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf16.hostedemail.com (Postfix) with ESMTP id C934F180005 for ; Thu, 7 Apr 2022 23:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649373069; x=1680909069; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=dUrof2VxTLYM9v29u7hGUQzQzbvw3951Xsun8u5eDL4=; b=T1xGsC7PZ5a2do6YskET+KgEV6hw3EbYHR/ZuCi4RwNcH1ndDOgOtvso uNWI+t5JZvrQLKWBrB1ELMBsMR9bRkEdgsAlpdHrz40XTWPmoE5ijFgaH S7ZKwmqfFRbR16RtbETD1LW9y5fzyjqTSc4MBbSwXQ+OG7+LTM7H7zdep 97t7mlS75VYPN8UZmGAX+42lEb4C9plkN/yxo5uRrjwJ7fW/RQNHj5wr/ FM8q2DlD0O+R7YQZKC7i6LFKxgKwaQe0ozwZMzRth2odira2ls69jDI2B 7EyrSiJ+BzJmWlnLXBl6Gz57fLMjcZVSBv7KgpOBrB3X2b4DIdGcFqw7S A==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="347901181" X-IronPort-AV: E=Sophos;i="5.90,242,1643702400"; d="scan'208";a="347901181" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 16:11:07 -0700 X-IronPort-AV: E=Sophos;i="5.90,242,1643702400"; d="scan'208";a="550276535" Received: from schen9-mobl.amr.corp.intel.com ([10.209.71.23]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 16:11:07 -0700 Message-ID: Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface From: Tim Chen To: Wei Xu 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 Date: Thu, 07 Apr 2022 16:11:06 -0700 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C934F180005 X-Stat-Signature: o3h8q1fo548oubygk4joap6houc8osm4 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=T1xGsC7P; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf16.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=tim.c.chen@linux.intel.com X-Rspam-User: X-HE-Tag: 1649373069-832194 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, 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. 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