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 7F68FC433EF for ; Thu, 7 Apr 2022 21:26:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C38466B0072; Thu, 7 Apr 2022 17:26:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE78E6B0073; Thu, 7 Apr 2022 17:26:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A87D06B0074; Thu, 7 Apr 2022 17:26:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 9835C6B0072 for ; Thu, 7 Apr 2022 17:26:14 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 63FB426485 for ; Thu, 7 Apr 2022 21:26:04 +0000 (UTC) X-FDA: 79331365848.05.CD520A9 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf21.hostedemail.com (Postfix) with ESMTP id 335011C0002 for ; Thu, 7 Apr 2022 21:26:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649366763; x=1680902763; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=mIX/4V9ZQLO5IL2OJQlDG9+qFrwjCz3AEf+UgwstfB4=; b=IJYWleQuZ6XGewDH9e+T8SW3WXP37K/NNECr9bfyCxlGHO3CQGw+rKzI 7uEcZxo54MWmiFUtdh0zJGDr2SgEhohOjVeSpl6dwm/X/OonpHt9RuI8p NPGO/15e+iG4UyAyqnNcUCmh+LyAXM7SRMpt2E1RkKjQ3IpVKCWzV2UgW qkOsagtkSeCPpj+k2dZO+QfJMABjSkZ66xuGlcDs2h3NRtmVsILLiL1dv j7PQjK6soDOb1pQ3hkzDHgtltx1mgUdZafeveIpVAzO+zZzJzPeD8aOQN w2O+9MvxpJIDO7p+0r879P0JvLE13n9SlYpRxcVXrGcHiQ4CD/2lYIKFa Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10310"; a="261136530" X-IronPort-AV: E=Sophos;i="5.90,242,1643702400"; d="scan'208";a="261136530" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 14:26:01 -0700 X-IronPort-AV: E=Sophos;i="5.90,242,1643702400"; d="scan'208";a="525096736" Received: from schen9-mobl.amr.corp.intel.com ([10.209.71.23]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2022 14:26:01 -0700 Message-ID: <215bd7332aee0ed1092bad4d826a42854ebfd04a.camel@linux.intel.com> Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface From: Tim Chen To: "Huang, Ying" , Wei Xu Cc: 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 14:26:01 -0700 In-Reply-To: <87bkxfudrk.fsf@yhuang6-desk2.ccr.corp.intel.com> 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> 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-Stat-Signature: imdazmc4deotunsgbduxi1qo6mzw1oab Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IJYWleQu; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf21.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=tim.c.chen@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 335011C0002 X-HE-Tag: 1649366762-3179 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, 2022-04-06 at 10:49 +0800, Huang, Ying wrote: > > > > If so, > > > > > > # echo A > memory.reclaim > > > > > > means > > > > > > a) "A" bytes memory are freed from the memcg, regardless demoting is > > > used or not. > > > > > > or > > > > > > b) "A" bytes memory are reclaimed from the memcg, some of them may be > > > freed, some of them may be just demoted from DRAM to PMEM. The total > > > number is "A". > > > > > > For me, a) looks more reasonable. > > > > > > > We can use a DEMOTE flag to control the demotion behavior for > > memory.reclaim. If the flag is not set (the default), then > > no_demotion of scan_control can be set to 1, similar to > > reclaim_pages(). > > If we have to use a flag to control the behavior, I think it's better to > have a separate interface (e.g. memory.demote). But do we really need b)? > > > The question is then whether we want to rename memory.reclaim to > > something more general. I think this name is fine if reclaim-based > > demotion is an accepted concept. > memory.demote will work for 2 level of memory tiers. But when we have 3 level of memory (e.g. high bandwidth memory, DRAM and PMEM), it gets ambiguous again of wheter we sould demote from high bandwidth memory or DRAM. Will something like this be more general? echo X > memory_[dram,pmem,hbm].reclaim So echo X > memory_dram.reclaim means that we want to free up X bytes from DRAM for the mem cgroup. echo demote > memory_dram.reclaim_policy This means that we prefer demotion for reclaim instead of swapping to disk. Tim