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 2CC7BC4332F for ; Mon, 6 Nov 2023 05:11:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2C328D000C; Mon, 6 Nov 2023 00:11:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B2A88D0002; Mon, 6 Nov 2023 00:11:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8539D8D000C; Mon, 6 Nov 2023 00:11:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 719088D0002 for ; Mon, 6 Nov 2023 00:11:11 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 760D88069B for ; Mon, 6 Nov 2023 05:11:09 +0000 (UTC) X-FDA: 81426355458.16.E90032E Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by imf24.hostedemail.com (Postfix) with ESMTP id D4223180004 for ; Mon, 6 Nov 2023 05:11:06 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jAzhV5jB; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf24.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699247467; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=acCaABroLfdDWL3vlR3iNFBy1xyQMGfZJ7A27xJKpi0=; b=YyZauQP7WMXj+a8RYXaUYx/N2KEw3RMgEhgTuLWU/HycDPKFdF3RdZq50lb+q5wGQnLuTs Djk9FdnWFp+s335wmEcS3KBs/Jgyyh2r7qPorDNFvLoLpwdiuC6Df+xfqs2GAR7BUGN9Vy w3B5NVGxdQTzO5irYs/GmfOp17oApNw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jAzhV5jB; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf24.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699247467; a=rsa-sha256; cv=none; b=gAlkSysLX/oHv6LUTEWqInPkpLXJErHy6TGzY6wwPcnict00wbmpna2flM0FYwOLxeAPel LAW0qIASZ8HdW61iKNbbZFcaSg+GBlT7nEedjgE3yS381sytzgX9uHmPMyQwXXM0fYp2SO Psy5mvSnGkyuydyKg4F8ocQgJWKaaog= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699247466; x=1730783466; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=wA9ps40setaaiWpMyonu1OKxCsVCbeCJDFHvPxuQ5v4=; b=jAzhV5jBXuOx2MPeoSVwShVzQMhSUu9MepIWEVJxWxCrAw8V4uG+QyM4 +jdpLSaaKhdYoBsRtQSBIZy4Y1boIKy/dBBjhYi0bWUcvcUq4Baz2CZZ3 9EJ/kFvF/yxylShajdAJd4t6uTfG+fG8AG48YNxT9oiK9pCa0uCWs2WET rb7bAfe3TpcxlFq5DmTK2b5mwYwg27JrvStSaGvPjHVLalcc+NOfo/d6M 2VfWzrSPAPOZmmzX1ifHYB5kLuM61Lxqvha0r8JofDUfR0wvPEuTsCAKm mnwpXCW4o5x0ChXkCArMq6VqAthkXWkeSs8MGPmxEZyT0Fx9PY4zccwra g==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="369414751" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="369414751" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 21:11:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="738693253" X-IronPort-AV: E=Sophos;i="6.03,280,1694761200"; d="scan'208";a="738693253" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2023 21:11:01 -0800 From: "Huang, Ying" To: Michal Hocko Cc: Johannes Weiner , Gregory Price , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, weixugc@google.com, apopple@nvidia.com, tim.c.chen@intel.com, dave.hansen@intel.com, shy828301@gmail.com, gregkh@linuxfoundation.org, rafael@kernel.org, Gregory Price Subject: Re: [RFC PATCH v3 0/4] Node Weights and Weighted Interleave In-Reply-To: <2i3awgkx2i4a5op7rtcqzv4yub376l66tevfvlyccf6wrjia4v@5x4ar4f6i5eh> (Michal Hocko's message of "Fri, 3 Nov 2023 10:39:00 +0100") References: <20231031003810.4532-1-gregory.price@memverge.com> <20231031152142.GA3029315@cmpxchg.org> <87msvy6wn8.fsf@yhuang6-desk2.ccr.corp.intel.com> <87il6k1y82.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzqzz502.fsf@yhuang6-desk2.ccr.corp.intel.com> <2i3awgkx2i4a5op7rtcqzv4yub376l66tevfvlyccf6wrjia4v@5x4ar4f6i5eh> Date: Mon, 06 Nov 2023 13:08:59 +0800 Message-ID: <87y1fbv578.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: D4223180004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pb9gcwwcntn8t1qem1579gcazokkt4td X-HE-Tag: 1699247466-983460 X-HE-Meta: U2FsdGVkX19kF/FjJi8WVsfWPQ9du2yxBDVac8shM2ImeiAADb3aW7cR3tg0mSO7f9JEMvgbtELkFlgbytWZ0+ZNWqzUPQ/xY9vUzs2/a3/sJBTbA4p2NjB3sV7fni/hmpKGzLGHtgH2jLIKOL3wvCiDO+BqouA94EoYtpn1JlGWR2Y+P9+5yg192RpYFsXVqaxJcDCoceT+3/zMN8zcx4eSrv/njKP+j590oFTpMeEirnDv2X2eIb5aoBLjvdWR3GXDw+LALWlN7QKKdqjcEyC9js4wUkGUb2JHBaS6qkRNvBJABSkMUdnIDmtrBOjj0YGkP6KYlB+ieZqWfq+JGvIjiV62s+dbfUTmLxDRGOvRkIAHv44UDEayHWyP9rUx2I7GAUzGH9f4hiLcbmL+4icSW8/pE6hH34AF2e5XZ1Jp+dTy44nRAQhCiXXhoGkI+h3uaZnQWUrRX6oPHcC5IhcfIfYRjLzJ329zniy8+EvcIM58Df2DcunIf/+89DGT/KLwHudlZQYYoBh4y0YYI8ARklwzKVHnCETJO26B6mPsRypQ5B60T/FXH1yvfUBdRUTmIKVprq+sYbU+8XVqIe96Z7XX4sZ7PmKuR8I5+L+UoTwb4h5Un2njk6BMnCgDzpeoBgcWHyRYpj+/GdX4zUtavVOqHDFd2E6CBoRapP4LPSJxvLjXVW89/6+faKngAhpUX/jCFHXCK6vEKeAU0nou54vqBZCaa14YoUv4cN7++xpqp0XtrLhMTmru6QbcATc8zOuOcn5mKg8XlLg36JJSmxIGtpiOvFUrcU2lu+JaVD3RzOipxdMJl+QUjNmyX1roC2tNwXfUanM5vS/hh61qXe0ouu2VyJv0Zvk7e8hbGShWOwrwG1FBgFpyH8iXII0FuMl75TkdhNL8FFG7ldhQlRClIrJeLUQ4whVf3LioJSWBGbDBrntOx8aLLorfYy5boZlCDm6gzbo4SBA cuIklhIy uBk3Dc3z82IeZVk6/OFBYDOjuSFf2im6M54O3TkQfrijQ3IMPdm72edS7gW2VCTPpiWZPoxo4e7yGjUlkYo2ZLhWO+W7lQIq+IoiLG7xrXOTYrfn8BYWRUEcmJWTl97cxX4Zdont51UxQ0cVDLtD0TA2ZHwNke1tzh5qCiqQeHC+6UOjKiQ2Qh4Iw+o0Rat2/NB0SziCFSrYPmmnCVwWCcxieLSzJnigPn7vx3ZrenL9nLaWHyK02cj/CZy4obCPMo6tRGcZfFjWfdKM2t2giuHf/iimaT3gmyZ4EYXbMEpzuGV9a9xuAu02EuQkd2DzRs1VY9QemnSefbsLFVNlWgUshEThp1haw/fcUb31L76yza1M= 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: List-Subscribe: List-Unsubscribe: Michal Hocko writes: > On Fri 03-11-23 15:10:37, Huang, Ying wrote: >> Michal Hocko writes: >> >> > On Thu 02-11-23 14:11:09, Huang, Ying wrote: >> >> Michal Hocko writes: >> >> >> >> > On Wed 01-11-23 10:21:47, Huang, Ying wrote: >> >> >> Michal Hocko writes: >> >> > [...] >> >> >> > Well, I am not convinced about that TBH. Sure it is probably a good fit >> >> >> > for this specific CXL usecase but it just doesn't fit into many others I >> >> >> > can think of - e.g. proportional use of those tiers based on the >> >> >> > workload - you get what you pay for. >> >> >> >> >> >> For "pay", per my understanding, we need some cgroup based >> >> >> per-memory-tier (or per-node) usage limit. The following patchset is >> >> >> the first step for that. >> >> >> >> >> >> https://lore.kernel.org/linux-mm/cover.1655242024.git.tim.c.chen@linux.intel.com/ >> >> > >> >> > Why do we need a sysfs interface if there are plans for cgroup API? >> >> >> >> They are for different target. The cgroup API proposed here is to >> >> constrain the DRAM usage in a system with DRAM and CXL memory. The less >> >> you pay, the less DRAM and more CXL memory you use. >> > >> > Right, but why the usage distribution requires its own interface and >> > cannot be combined with the access control part of it? >> >> Per my understanding, they are orthogonal. >> >> Weighted-interleave is a memory allocation policy, other memory >> allocation policies include local first, etc. >> >> Usage limit is to constrain the usage of specific memory types >> (e.g. DRAM) for a cgroup. It can be used together with local first >> policy and some other memory allocation policy. > > Bad wording from me. Sorry for the confusion. Never mind. > Sure those are two orthogonal things and I didn't mean to suggest a > single API to cover both. But if cgroup semantic can be reasonably > defined for the usage enforcement can we put the interleaving behavior > API under the same cgroup controller as well? I haven't thought about it thoroughly. But I think it should be the direction. -- Best Regards, Huang, Ying