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 E81ADC4332F for ; Fri, 3 Nov 2023 09:39:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45AFC280015; Fri, 3 Nov 2023 05:39:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40A7B28000F; Fri, 3 Nov 2023 05:39:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AB42280015; Fri, 3 Nov 2023 05:39:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 18FBE28000F for ; Fri, 3 Nov 2023 05:39:06 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E1C9140DEC for ; Fri, 3 Nov 2023 09:39:05 +0000 (UTC) X-FDA: 81416144250.11.CC873DD Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id DF8DD18000E for ; Fri, 3 Nov 2023 09:39:03 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rN1523AA; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699004344; 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=d4jQ1t6Qttv+buPxaS9aV1Pqc3DF6sKVx91vpC38npY=; b=Mr3psBOU/aCVFnJCp2HdpMOM48mvlNEgEoULVoxDNdfjk05HE4FEeYRu78h7rlUP7+5nfI dqZlsfyyLxxsqY5/Dw9rqxvAN6w+PmY5Od5wGK20wey4swjodoRxTvY8hzlI2cNOdmiPIN SWHEBdl3CZdbwUjo3itQ0r++T3/Fmw8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rN1523AA; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699004344; a=rsa-sha256; cv=none; b=Qyrn2E4bYiWA+sdfLPa84Pg/LVXqNnr9Fgy8zOp1NkuXUgYioRyolm3Yl8tols+PcMOQwQ MPtlpn7+uzNTWT6xS4RTNxXDJLy5BRd65OxUzGkPnwfixnofvV4jkzAVTBh3G5RlKGXUFf dLODNWOVr13jd25u9sIDQvW7OHAmzMw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 707481FD65; Fri, 3 Nov 2023 09:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699004341; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=d4jQ1t6Qttv+buPxaS9aV1Pqc3DF6sKVx91vpC38npY=; b=rN1523AAByVvwQQ/Qv9+31L7Z+WHkVB7hPMA096juan6k4125M0ZQOhzSO7JZhqZMrZ1JS pFxT/lA0OJTUYGlaY1TNJ48TlWQcrVj/cDTMOytZZDztDCgBpTpSkgRd5yFDZHnBab6FTK cGuwQvdUA8Ofc+FocFMkm6rdt2ZHQvA= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 51D3F13907; Fri, 3 Nov 2023 09:39:01 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 2sE+EbW/RGWqewAAMHmgww (envelope-from ); Fri, 03 Nov 2023 09:39:01 +0000 Date: Fri, 3 Nov 2023 10:39:00 +0100 From: Michal Hocko To: "Huang, Ying" 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 Message-ID: <2i3awgkx2i4a5op7rtcqzv4yub376l66tevfvlyccf6wrjia4v@5x4ar4f6i5eh> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87jzqzz502.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: DF8DD18000E X-Stat-Signature: e5arwjoaxwi1wckm84ybyciqhjufmr8i X-HE-Tag: 1699004343-665823 X-HE-Meta: U2FsdGVkX1+JDvNlTuZEOxW0AeCDs6mTzTewpNcz/uLYotBDeT/8mcVCOEaaaqkr38bZl5hD8CIqhw0jYg+0HWQc52xiEW8TNF4j5ekLSWChE0tgu5CLFRJVYdqMXQkrJ30dXjWj+vGNCThli4Aeg5m8Bx5KFH2Z7LNSRl9d+UDs6MOqvrl1T7aRSW1q5HwCNNCOrxOzpCVvI102nULazQ7cU0D905AsIWdgPI+/a86YpHlV6I+2hfpRXlmHWSdrFuT33/ACkqsVYty4DqfE624QdDzuTwjDf+jnECi4MpUSHDom8bBBwJAaNkDR9WI8VHSxsSbnKak0KySGGDEY6ai717dxyUiD1Tn6Tq/DuHuvlj7vyC4/Lnyo0IO1snLZbN0Y4tbzySK+oADfvCnvWNXOvsKu7+OR41qb/TdffyhCYFlcVbhhnZbJH/ZKsUorPjcy6vy5O2tYlO2JSoBWeOLPo+Oo4jbKhRnmIW5Nn3uHqC+3N5GkCyMhrVjNHl08/OcbSczdop+3VbYJXuogpx8q94nV+YHkhS66Lyo6iKTIEmj47w9RMTB1CLeOrsqhmgqu1KoccpOnORN81VzZ1mHQGTtJCb/qr0X4Bl2ZbohinhJnvScoDDwSgy0bexhEmh65mU82frJCaIgwJIEJuXhCmQVtcNBWcFCCP8Y35aveGx3zacQdBAWEmvvXtzqxyWGRaEJR64CyGtyLaROsTtpBmQHcpJmDsWTlRkZVrrkifArrEYSGvZPvZeTs2zLMLujJ/0dfhW4i3OpF7YndJ9MZKBNxyQwbiMX6VPpYjfppAhRxMJRQ/BzBtxGOLKx6iW3Hq7p3LjXPLlsB2YXt6w0y807vI9QJgTKpBgm5LnP1Ypl5cGvvoyHqQp2IwQ2Kf2pXgHs+YsZ5Gfw21PwEROanLn0Rc2LXVuQhSWw5VSq6GMA5TFYgoxUCBjgDvyYwwmucLo5rsnCNMTb+dRx PS2xpYHC YR4IH6Ps9hkbctsNHWHo8MGn6T2psEefqJKT+L/27gEZeoml46965/KNPbywO/RELoDilRtkhskU+ErlaLJH41d5oMyO1mRM860hPr5jeoX59flCgXJXl0lHta0b125cK/x+XJaACdHqMDTievck80AN0GDQ8LvV+ZMj88xcsPhLkKf5PFHxSkJGK+A9nBcMPnZwxZEfdudVXDgfzuKX51LkxslGBRfmUnkTiTcZ1OAdfXKvUlk4X+3993sS2mauhm595at0+EGBWyyQzxs/4c7jCjphxgU0z3zi1/xa1WxowffXmj0JcNIvTILe06ZGdGE0wQxzJOI3o0xdXClTPz1jth8N0iGrSbcPIFzZNv5p22vjsnL0FBpu3Mmynv96bG3Bl3DIcOHvSjRhJ9WfWlOK4pQ== 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: 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. 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? -- Michal Hocko SUSE Labs