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 7F8E4C4332F for ; Wed, 1 Nov 2023 13:56:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1FC28D0047; Wed, 1 Nov 2023 09:56:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED0858D0001; Wed, 1 Nov 2023 09:56:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D98838D0047; Wed, 1 Nov 2023 09:56:17 -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 C87728D0001 for ; Wed, 1 Nov 2023 09:56:17 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6750F160CB8 for ; Wed, 1 Nov 2023 13:56:17 +0000 (UTC) X-FDA: 81409534794.29.13CDE7A Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf17.hostedemail.com (Postfix) with ESMTP id 7325440006 for ; Wed, 1 Nov 2023 13:56:15 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=us3V77aq; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf17.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=1698846975; a=rsa-sha256; cv=none; b=7dk3sIT0dvWJ+OgxszENg/I9ZAvAr2aFueva5gjbWhI4WG9rCp0VzKZm6jzRGbHXQQpQEM mFtyH/NI8imlCxPntcUJe8J9ICREMBAhg875q97Xae3tiqkKRHfV9jGu6zJXJy2PzsqJ0q M6uLd7hxtWdyFNnvLh/dPNfgltez5Xg= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=us3V77aq; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf17.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=1698846975; 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=x8Km4F84mpULmElKD15zKPWF2o5JoVpwXMz8cd2khw4=; b=ZUZY3b+raMyVLwccXfoDAlpeQTHNOeJNBZ0h3n9kVmPLSk+0cSOqg2QZ8mehBzyIYk/KWC 8SJRN5D303o/v/y7+4pJ+1b31T/H1xmckl149hdFTiv4eOpRaPI2KZLK+PlIJCh0y8SpZj bUB8/TgybzsMQOm88yPJrQTmrPgWCRw= 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 2879C1F74A; Wed, 1 Nov 2023 13:56:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1698846974; 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=x8Km4F84mpULmElKD15zKPWF2o5JoVpwXMz8cd2khw4=; b=us3V77aqb0oYcroJxa/NDISGJQJvGqjB4Llh44TPoJpDPSuAyRAeXc4Z0a86f38p9S09Pg RpgLws3zQ1IvWALtBg6sEkVFlkJ94WA7n+IZGVzQt5v/RN4JuzpEt/rvxSBbr0+fKF95G9 R09UJn9lh7Gs7R8FcbYL602MPq3gyoU= 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 0441F13460; Wed, 1 Nov 2023 13:56:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id GLyVOP1YQmUQfAAAMHmgww (envelope-from ); Wed, 01 Nov 2023 13:56:13 +0000 Date: Wed, 1 Nov 2023 14:56:13 +0100 From: Michal Hocko To: Johannes Weiner Cc: Gregory Price , linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-mm@kvack.org, ying.huang@intel.com, 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: <3ilajsu7rlatugtmp63r6ussfdhqoxokj2vgmx3ki3zmx7f5po@i64b27upx5qx> References: <20231031003810.4532-1-gregory.price@memverge.com> <20231031152142.GA3029315@cmpxchg.org> <20231031162216.GB3029315@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231031162216.GB3029315@cmpxchg.org> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7325440006 X-Stat-Signature: pinzh6cd9wkcytp3hyi54z5jkk3tcag7 X-HE-Tag: 1698846975-299413 X-HE-Meta: U2FsdGVkX1/4Q8bNeIVUwKpUjyQt5DUGxRpZzVwhw0W+2ZVIrnB5g9NXTQYa84mPDSTnrd5a2dKXCI1qJw6Fclw/2wIXOq5iWW+Ls7PwHD8UJR2iAx3gCkgkO1/1Lo3YYOIE+TXksK30QSpYABlwa1tDbskrq/K2yXY0ZWBR3qio6XzYGJ/M+3fzYSLar1+DNDapm8WlAcDvkxl7fp7TjEzaY+7/fhX7XouR/MW0LwpChCR5IGqB/4p6nTTbZrVj675fcr1M1j+1bJkY0AuOmza/Xr3laHTkHgSQIg23OleXrSNDihd2xXu/DBCu+nTGADkNrD9Ej7AR5cyuzuB0mWpTfqU6dRrtegfHWLPH7tjc2J2Nba8U+ixE6PKfAQAGEK8E+tIEeT11wu+MHArZRJWxwUOzMomuyTPFMvJUcAfUiaabQUOBznLD7ygwrHibb6cFeeFHoTlc1aITppiSWH1At4dCC/nPQFkYaIEuYLvrpG4W1VMIb8cM9vznBWod7lp5BbPZb687r7ny9nJhSF6sU6nWpkKaRDO+jC5oOqsdA9oZtYkFpe+zeaVPFo0opRUV5iQczDm67zjfmGwRyFBVsASov74Xx2LRzF1aScqmP5hxd5AeSzwNUUNy3U1Qh+iAE2zlApZ3d77qUpDFSVUeKUL223Wc4aK7o+cdKVaxvIMqiEJxZLyx73kG8zK9pbjfARU5WO9IUWDXV+eWSQJGoV/KVv6k0vTT5QNRfwY/59n4qbGwQzjDEJMO/BPFbr3NcVz7/wpsc03Cp+njzt+yg7EuQDvu3qB8pH6SniNcyWsxM/Kn3IVjAi5GOk8ZUBY6CEuAPoKb9aQnJBtXXN/CbHx9M0pLkHhNglR461Iw5Ba5G2csgbws84vyaoRPJj9pSBfG7+FV+4mxAPL/QTLZbHP4qe/U5VtGkg9LIMU8OvMseLRry/U7RXPvhoLKBVaY8mqq/ZiqgIALHRo YufYflud jMi5xlbOTk4Lc/qT7IkEbA5T6BiNegHCPf5S7yRyMDqIjYWNbOpk1bRZdDFB7xB7cSWyxqVqZVQBUoM0o7WYdDsx+/WmHGHDGMvr2u3q+28yqj+EL3McQX3UdFRfegC41CG/Ww9x67Ng8OIOoxqe5eBmcGfI+vb2h9Rb0ttu8+IeCKFokWo+12zCrtpbjfcg0X8xkCUHifo8iFWAp8KQfAOjh3qFxYVhJNRuluaqc5H1CVQqbe5/Fp7wCR0u+Hq87GFq4FWO811trX9s= 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 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. 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. -- Michal Hocko SUSE Labs