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 991A1D149E7 for ; Fri, 25 Oct 2024 19:28:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 145716B0082; Fri, 25 Oct 2024 15:28:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F5986B0083; Fri, 25 Oct 2024 15:28:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F26226B0085; Fri, 25 Oct 2024 15:28:57 -0400 (EDT) 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 D40AA6B0082 for ; Fri, 25 Oct 2024 15:28:57 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EF6861A0F89 for ; Fri, 25 Oct 2024 19:28:21 +0000 (UTC) X-FDA: 82713111432.08.16BC066 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf26.hostedemail.com (Postfix) with ESMTP id C46C914000D for ; Fri, 25 Oct 2024 19:28:40 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=F5HZK9Zy; spf=pass (imf26.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=1729884381; 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=TAMj3Z9lHHO9yLeo/16PKWQOeFKFhlCNwIoJB3gQwas=; b=o4KLhPGPTHP+z+heAQ3xsUhjSt4SiNum9onBl9+n/k30dAcnkNPY++WqCN5zmw9fSqvqJP P91SyUhgkfTXo/C4Q1mxiul+id75Adr5fmdzvfBobOI+BAIET5+dwNHS/866joRpEMca+K 52OxFIMV6vV4bpKhPha8wFYVePfhNao= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729884381; a=rsa-sha256; cv=none; b=rvuuU3lHO7GQ1fIs1ALMbBUT7EfLlYGgbrURUQT1oxGey3015jb9Fk8jF+2P+HOjwrsoNn X+cI/2dV5pNgH6+Sj4oLo/iwWCqO89EYBKRVeKqGDHtzpZ5VdBoDOn16Ag0/mBaRgWBARs EUo7eBlN5XEK7x2vraMK4jSeKSNShF8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=F5HZK9Zy; spf=pass (imf26.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1729884534; bh=HmSSwqaEV93zmIkQQrgyN/H+4SpePg2bLhbZrxFkUvE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=F5HZK9Zyud8fxXPO9yzo8uVn8HvBmJzw3ALph0CQUV/52RTu0J43yWQYy66x7qIac fdFV/idJwlHWRF1mMoJce2/a4Uyql2W004hVL02EJAjMDq+rzmCkTrhZ4Ezu6I6eSy Ln882vz9nxSGn40SIoBYxbCde0eHZpoXclU/rbrs= Received: by gentwo.org (Postfix, from userid 1003) id A19F6409C3; Fri, 25 Oct 2024 12:28:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 9F74640681; Fri, 25 Oct 2024 12:28:54 -0700 (PDT) Date: Fri, 25 Oct 2024 12:28:54 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Peter Zijlstra cc: tglx@linutronix.de, 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, llong@redhat.com Subject: Re: [PATCH 2/6] futex: Implement FUTEX2_NUMA In-Reply-To: <20241025093944.485691531@infradead.org> Message-ID: References: <20241025090347.244183920@infradead.org> <20241025093944.485691531@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C46C914000D X-Stat-Signature: 31ptozsg77ha1oayfoed8y46p5mtdqmy X-HE-Tag: 1729884520-274467 X-HE-Meta: U2FsdGVkX19cUDtkDmkrlDlccoiLLlK18aB9KklvZxrxRpq+QKxxmn0STFTVfnxX3lQJnNLdxRwYVKJnIZAUnd1NwCURnR2wvkMab7u7KWlDJVL21j9RLQkWc189czSgRbedbHt3XfY/9rFzyAcfWNKCr2ed/KGZn/KibizejZ+XmMjxWqK1VTfy44IsOdx3SLuPOvx0gYz6gvEUrBacLSWXBhv/JrD3CqkkJFuM8Jie38qUw0nLNOR1LC8JVhNiImabBiV0CXmTEbQZ+ZUQm7+Tg1hyRpOVyN9mpOybzVYVHjrWWKKiybWiXj5mr6Cu3yNqE0ArUPcSyHYaWWGr7aq/WcsLDwd6TRka7Lf5gjWRudYgEJtrmT3GVu6HIX7wsZ73njKmdQhS6lWmzUi0MML8IAmOgLWOXoC6tKSfvHlMwxUiLpbPS0y8cbyEjSR9jMMTO6odF0rlVUxE/BDMi+gI5aTE6bl8Yvv5V91EX3j7jDmQR7GPz1CDSlueji0+d6SYVDr9ojOSPzwIBrxgGecbPnomamgh9Zf/CM5eu9FKQ1B9cjBssmq9wKrT0tUIDRgVmWfUj0eNPyBU0CSpleIPalFs08u6rGrDLvZEA7BFOA8IflXqAscYVvf58CZSaXJbQBMcFMgEG/mFyR+3BDRod2PoWJGpI9y2El0I1QUoaatp2I/WtIyH4Yd3LVExn2jKDxIf8jPF9LjotQhdNfbHm7q2wVUWg5Wiy09Kkg471LM02XfiBgQiOXqS8jSQOUzdJtXzBxjjcAey6sqCxQmD1NRnwnOVSSS1vCNVTJsSxrMHC3C9M6J25iLwLs8FtavieLi+GifKECcl9dWbeQfgKSasDfWKkzbsLjW430wO9g+x1/XydNWUv4vz5vuJ7kxJEqTRjJXop1Ap0fclg167xSj8ATuH2VK1c3pCEkAKxWP6CWDP6tmfzsneulFlx6Lpl7lFrj2R6UKk3Ic WWK8Qswe v0UhZyQUd27DcCo1HkaaI8GlggFNzPVDemso5RUrH6H8k18UDqYiL39CWbzWFgPh6MYfwGHTCQftcUsHcROkTZgc8bxt2KOib1Qji1Hot6j65w8OsX69kqLOHaz6Civ3hEdlLqEUTWFXOkI+AJGUjbXY5TpIkZ/qz1G+BE3qTKs9ZXHen1msYDAyDwUBoLL+k2B4zcn0zM8yihHUXlFPgY49ijPjf2KRzHQ2RXKx2mc2DoHbD9LrsVUji1A== 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, 25 Oct 2024, Peter Zijlstra wrote: > Extend the futex2 interface to be numa aware. > > When FUTEX2_NUMA is specified for a futex, the user value is extended > to two words (of the same size). The first is the user value we all > know, the second one will be the node to place this futex on. > > struct futex_numa_32 { > u32 val; > u32 node; > }; > > When node is set to ~0, WAIT will set it to the current node_id such > that WAKE knows where to find it. If userspace corrupts the node value > between WAIT and WAKE, the futex will not be found and no wakeup will > happen. > > When FUTEX2_NUMA is not set, the node is simply an extention of the > hash, such that traditional futexes are still interleaved over the > nodes. Would it be possible to follow the NUMA memory policy set up for a task when making these decisions? We may not need a separate FUTEX2_NUMA option. There are supportive functions in mm/mempolicy.c that will yield a node for the futex logic to use. See f.e. linux/include/uapi/mempolicy.h for the types of memory policy that can be set for a task in current->mempolicy. MPOL_DEFAULT get local memory / use system default policy MPOL_INTERLEAVE interleaved over nodes MPOL_BIND use the node specified in the task policy. MPOL_LOCAL get_local_memory etc. You will get a page or objects with the correct node by calling alloc_pages() or kmalloc without GFP_THISNODE. If you just need the node to use then use mempolicy_slab_node() and assign that to the node of the futex. The function will determine which node to use depending on the active memory policy.