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 EF461C4332F for ; Thu, 2 Nov 2023 06:24:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F81E80016; Thu, 2 Nov 2023 02:24:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A7B68D0026; Thu, 2 Nov 2023 02:24:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66F4B80016; Thu, 2 Nov 2023 02:24:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 58E4B8D0026 for ; Thu, 2 Nov 2023 02:24:00 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 134641CAB07 for ; Thu, 2 Nov 2023 06:24:00 +0000 (UTC) X-FDA: 81412023840.11.116FB1D Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by imf18.hostedemail.com (Postfix) with ESMTP id 63EA01C0010 for ; Thu, 2 Nov 2023 06:23:57 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=B8QGLEmn; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 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=1698906238; 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=WD70PAkWys/bk4yMECwqpah7YB/EuFIwkwN648onzDQ=; b=PxUnqTjQ13ZBYy/ZASURg+SGDVKtyxdgzUdzTeVJvJj9M3vBuzPZCDE8MA+DtaHq5YJ8e/ A2iaV7tNVdn2nZVSffAOh8eJs/HAbHm5PQw87mhI2vB2BegAkoWE6WNTgi5eJMTUPWPI3t XSc3FLecSNSig0WEJDMbg7KTSBDPa8k= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=B8QGLEmn; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698906238; a=rsa-sha256; cv=none; b=ApKPsdmlkWJCtSioLqDZ1cvpAvYVI8JnFhAIDD3qPpuG3kHdFJTzf6XQmqc3jj4WFHnGNn pmRKJOP8+p3oXKRu26TiG1sQ/1dfwBXTDG/6vHgZL0eGT1fapOJbY2BCBOGT9JiHlvflSl Cec/d6E7qbKYSr+fotyp4A5hNMNPDgU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698906237; x=1730442237; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=STdydUh5mAz26anwvBBVVUpUuW54oz26dqCeLmmOLA0=; b=B8QGLEmnx+KppkL3LsGtYuH74d3ZD8y4XpYK8d2JFCxChvmO06fG4dPY 8VWo1WjwCozKxXfOF/5Tqxxrb0GaUw2WTkEPp9mrPr2EtsnQAMUiC/KpN 2eKiQOs9eNJj/K8Ll8EQd85R9Dk6JJLPDnXojYU0ReXwx65fLe2AsYDjO 7XTGC2om7aHJ8o3cJyKhcCKW679SvB5whirtcGDzE7u38U0ehYWphbqfg yf4lTZ8fEldkmoIPT1Fr7nk2NN/Ob10LMcXihae24tVrY8eR144wAdRdI bYAVqmAOjg0KWo7EaWDbDZIYjw5VnlkO7ZisogF/8GQ61POKYJlUiWSFr g==; X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="474885222" X-IronPort-AV: E=Sophos;i="6.03,270,1694761200"; d="scan'208";a="474885222" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 23:23:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="711036350" X-IronPort-AV: E=Sophos;i="6.03,270,1694761200"; d="scan'208";a="711036350" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2023 23:23:51 -0700 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: <3ilajsu7rlatugtmp63r6ussfdhqoxokj2vgmx3ki3zmx7f5po@i64b27upx5qx> (Michal Hocko's message of "Wed, 1 Nov 2023 14:56:13 +0100") References: <20231031003810.4532-1-gregory.price@memverge.com> <20231031152142.GA3029315@cmpxchg.org> <20231031162216.GB3029315@cmpxchg.org> <3ilajsu7rlatugtmp63r6ussfdhqoxokj2vgmx3ki3zmx7f5po@i64b27upx5qx> Date: Thu, 02 Nov 2023 14:21:49 +0800 Message-ID: <87edh81xqa.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-Server: rspam09 X-Rspamd-Queue-Id: 63EA01C0010 X-Stat-Signature: p6j88i7cixsg6m6tnzysrx45sj44ecb6 X-Rspam-User: X-HE-Tag: 1698906237-602354 X-HE-Meta: U2FsdGVkX1+KHjlicgUryS/5a6A11NBiYqiCLvIgnQQydkHTxpyMJa4W+oQfvRliuA2ll2/MEB14TYiPSf2yl/62biAAma0AJH5G1AqG+vR4xGRD3KQmSUbU3BVH3KMgNz+CLS3uppmylqzVefkQtuF+83LVqe8F23TyGGcDuzUfboHn6gZmM8rLSfxofaTaxuMuFOIl3yTZGRofQiRb6RM4hp42rGZTkCKsJBCFg9VaacFQuIkjBxEhLaesipsUuLwR3extkMvGBag6rr0K/gKTDOxsQiXL+tkOQ1oJYLt9OsMUP4uU8ciVPab/H8ay3t8IM46q9dj2uYpv1C3qRdUSIi38LmXFruxLyNV1ituAtwx1u99sw7xX9wRR1nAvUTnMGDxar2iCyGP6hzpPxPNVNM0UYVIRsrlPjOnNoyocLFEkJYkB7P7u4ivJT1CNYUvxtfB/ILwZKOsY0KkTIGbWZ4ZUdt2ZyB++RXxCnj8uRwVEABfD7d22x0v1/PRTF4F73Xg4T2hq6FVXQvt2QlHX0d8LhwJBG0l4UhcHBHBbJ/Ie+88c1rbCO+kcpe5s1WzFppeDZjF2V64H89KoLn55wYTGdpNCyDGp34RAF1LXc7rL3zctaZU4fwiCBahzNY5V9wfuFd/YOujtwgO4xdPaB8J5LolE2TDZfEALFAZ0HJI+ps9/++gEXfhNGZVRkpPKE+iTg+YxK28tSfz9lZTRtw0oAQf+OSfvmrjibqhtBwaE31r917+O4ss8A/pxPdVG7wXqpTQbsY5/1liaT5iDUAwEaxMWCzybrdvJgWr2Xu3nJb4C7fZ65FsASUYASdecJCQJy3KivY7/U7Q80x7aq7vW2cchZsD87Zzw4b3IJQdVtBQzapsrAko98au0JdNe6XGJcO59kvFuwFieMp2hsZ0+7wTHllbI7/oVxJtXJY0KtRHVE+uuIq9V8/xMH8VG/z8I+53uUG7W2A1 dSo64HoL k/aO4cUGwoShyJT7W1LmEYFczMzJECchN0WArelf/eyiW+/zsVi+4tIJn4zdH0rdXmyXn5zxLBVDSf6/jpE+XuCP5MeXawfM2kqwtPhIVOU4H69msxFOIsAE7+OwPz8r8R1Zb9XGezmSN7a0NLHw4CttB1XOWdNNfb9H/CkZV3O/+l0nEep6/a0BJNwjD+pEjDxEGhIUy8q4na7YDeKDsj4lRHGZOntdHeplFackvn8g43CKWBYWbI7RNxHzdF+KVYy0UQdWx9KL8bf+VLYl5PnqWmxVR0t4gJflupYzTAVWLzzmpYP+QqwxJ93hXUe9+nDrb1mE2r/M/tMdBHSetDZuAW3UmXlKstHtgmsezr5DYC3G1BNJIo5ZwdX5q09CBuZMIApDXgqGrqV8TcVVI4Iu3dA== 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 Tue 31-10-23 12:22:16, Johannes Weiner wrote: >> On Tue, Oct 31, 2023 at 04:56:27PM +0100, Michal Hocko wrote: > [...] >> > Is there any specific reason for not having a new interleave interface >> > which defines weights for the nodemask? Is this because the policy >> > itself is very dynamic or is this more driven by simplicity of use? >> >> A downside of *requiring* weights to be paired with the mempolicy is >> that it's then the application that would have to figure out the >> weights dynamically, instead of having a static host configuration. A >> policy of "I want to be spread for optimal bus bandwidth" translates >> between different hardware configurations, but optimal weights will >> vary depending on the type of machine a job runs on. > > I can imagine this could be achieved by numactl(8) so that the process > management tool could set this up for the process on the start up. Sure > it wouldn't be very dynamic after then and that is why I was asking > about how dynamic the situation might be in practice. > >> That doesn't mean there couldn't be usecases for having weights as >> policy as well in other scenarios, like you allude to above. It's just >> so far such usecases haven't really materialized or spelled out >> concretely. Maybe we just want both - a global default, and the >> ability to override it locally. Could you elaborate on the 'get what >> you pay for' usecase you mentioned? > > This is more or less just an idea that came first to my mind when > hearing about bus bandwidth optimizations. I suspect that sooner or > later we just learn about usecases where the optimization function > maximizes not only bandwidth but also cost for that bandwidth. Consider > a hosting system serving different workloads each paying different > QoS. I don't think pure software solution can enforce the memory bandwidth allocation. For that, we will need something like MBA (Memory Bandwidth Allocation) as in the following URL, https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-memory-bandwidth-allocation.html At lease, something like MBM (Memory Bandwidth Monitoring) as in the following URL will be needed. https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-memory-bandwidth-monitoring.html The interleave solution helps the cooperative workloads only. > Do I know about anybody requiring that now? No! But we should really > test the proposed interface for potential future extensions. If such an > extension is not reasonable and/or we can achieve that by different > means then great. -- Best Regards, Huang, Ying