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 23368D5B845 for ; Mon, 28 Oct 2024 22:32:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1E456B00B8; Mon, 28 Oct 2024 18:32:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACC216B00B9; Mon, 28 Oct 2024 18:32:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96CFC6B00BA; Mon, 28 Oct 2024 18:32:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 79DD56B00B8 for ; Mon, 28 Oct 2024 18:32:50 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 27E5A80A23 for ; Mon, 28 Oct 2024 22:32:50 +0000 (UTC) X-FDA: 82724460462.20.9FF4BF2 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf18.hostedemail.com (Postfix) with ESMTP id 093681C000D for ; Mon, 28 Oct 2024 22:32:37 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=GLKH3sYk; spf=pass (imf18.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730154689; 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=/SQfm4OrYQgNEi45Oobeb5cLHvXvjVCoOTfBN4ilzVA=; b=gW/bSh8FK05QcA/mui9BX1CISngH4rQQ4NpiX7DPcttRAGpS/SwM9lIKFfW7/WMoIfgGPP KZJUCxxxv7cq5Htnc3H+zYF511xZ4ChL2y+agDIgR6Tgc8dhlpEUj5KkW01LFxlOuBnkC8 q14EzZ3uBOSO4Fa2oCR4hZH5YzgIvns= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=GLKH3sYk; spf=pass (imf18.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730154689; a=rsa-sha256; cv=none; b=EaAA1Uzov5LysCIO1CDdYDKtV4gIzCKNb1tY/6E/f66v25wHOiB0Qgn2rJvbq7Ch9y90QK gP6IJZaexCCC3El568E1xoTB+DM03yoJnqKb8XYPlD0nnonF18CcTPDmGIyflsoW9xbj9S LrMrxpboLp4Pf6l97VzNbsF8dIQkSew= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1730154767; bh=/SQfm4OrYQgNEi45Oobeb5cLHvXvjVCoOTfBN4ilzVA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GLKH3sYk+S4es0N2N4PStmrEczBQ1YxzIL+RLE5xGsBFuJ8EXAIBI1rA6Vus9OFbe CdoPMeXkRY3Y+lQpGwvA7oa2XvmvSmLAqQlOCnkJTrJ25AAbBlDxhudod85i56OrjE 1VLsKD9Aab8OZOvPWSpIqstwFQgcBMVY1IXhGz/g= Received: by gentwo.org (Postfix, from userid 1003) id 2163A40262; Mon, 28 Oct 2024 15:32:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 1D9CF401C8; Mon, 28 Oct 2024 15:32:47 -0700 (PDT) Date: Mon, 28 Oct 2024 15:32:47 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Peter Zijlstra cc: tglx@linutronix.de, axboe@kernel.dk, linux-kernel@vger.kernel.org, mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net, andrealmeid@igalia.com, Andrew Morton , urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com, Arnd Bergmann , linux-api@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, malteskarupke@web.de Subject: Re: [PATCH v1 11/14] futex: Implement FUTEX2_NUMA In-Reply-To: <20241026072119.GH9767@noisy.programming.kicks-ass.net> Message-ID: References: <20230721102237.268073801@infradead.org> <20230721105744.434742902@infradead.org> <9dc04e4c-2adc-5084-4ea1-b200d82be29f@linux.com> <20241025085815.GG14555@noisy.programming.kicks-ass.net> <887eadb6-6142-3edf-0a25-d33b2219b90d@gentwo.org> <20241026072119.GH9767@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 093681C000D X-Stat-Signature: q99m8qcej6bxui6xuydpr8w993e6d5uw X-HE-Tag: 1730154757-369172 X-HE-Meta: U2FsdGVkX1+ButDHAUnx7TOUkvxYEhmgHnZcrwHgPGLnzXvGrBN5BEM+pAGgoZ50p0FBopV9y+BYex1D5YIfHBEKvZxL6xXIa1Gowa+DuZ3FxPi6itKKeHInpbofkZ6EcLLKQP6Qs3ysCnRkgTg+QQoey+TQ9cAECPq0w/Nn4BV865vGYzfIih/L4eo7RIJ4gqtPKeSDSPbNkvkEfICuS0RW5knvyJCOk2UdWbjaEja5/wYr5OgmIIhG2KALfCgWF0f7lp7ZoYuu9D+UsOI60YKj26TKSCxHggiHUAyST9ebprxgL7fXDvavoE3jVJhbKI8PBvpoeYT7KlEHbCfW8SjwzkPwoAKQFY/jlc8iCCI+AakGnFAHAlwE1O0eeAHJ0m3ttQGCvRe7GNzhQ4SyUh0IbywoMoab2iFdyCeAgZg9Dzf4Nn1I+47FOEf5ZhlWHqcPlqYVAukgtX0vZQWpo/Dbl1JxcAyM3lrPips/HUkgBHtXTcARZoC7zA566WREESG+rWq9PCAehw+T7xArdM9mopEXHot6CKjnpIDRSPkzKRLWkZb+kWQ+G1mCISncsYqC6Eb1mAak6cEiTYmSEHGsEDzA9D+4naQlKLJRWU1yoOdhTKulipmT6HR4KlmhzU2KYc9O78TbRIbWaYROE1DYO5uFo5j3IhzEsZXuRZbkgYPR3rFqLOrrES2lHU+T9HYCl7is0iFKg6FTHxOHGe0bnCdVc3C/HLhov4CWQRfAGdXsen85PsFb0jUNCqltKo9JUZUN+ZGw3YS5HE3j4YTqG+vd0Q54tQZOPQCXXVRvRqKUTlq8GZ9CC0uLm1b0fMRbfp54cPzlaEtZgDCFIBQr71ctj7244Tu+2uI81cM52NmV1ThB8NpONzKUIgz4SF+wfxBTgpOJjDA1wHsyFBUiPVXJP6klETq2wdYsRSTXpDNeu1XmWsFogD95Np1Ca8zSfuZK5U2+i/t/YCg NNPCzDBt z18QxCakqtbEbrEoGSN4pJ3XiRgHWdv+DcWSOuKru4URDLtx/G/S9OJgE53Zj08AChcknu8wvqDkci+67sySukDP9xWqmF23KxXj+ZdrwsNaZy+yq8b4geFF0mzjDDfUGEC1ywStDSZFVAvmOY7fl+bVpT/OyUdbhsPQZEYrKdkFI4xK6exXXuBq92hJ3Zl+c6ds4lgUNlKlD3Fv31LC+lMeqiqQfcLi/B7jWK/GiIFIogZDb6GB2Np9JxA== 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 Sat, 26 Oct 2024, Peter Zijlstra wrote: > I'll look into the per task thing, which I'm hoping means per-process. > We need something that is mm wide consistent. Each thread can modify its policy and that is used f.e. to control memory allocations for syscalls. For example a thread wants to allocate kernel metadata on a specific node then the policy would be set to that node. Syscall is done and then the tasks resets the policy to the default. mm wide memory policies are set at an VMA level and are associated with addresses. > But since futexes play in the address space, I was really rather > thinking we ought to use the vma policy. If they are associated with an address then you can use the address space policy.