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 A0A14D5B845 for ; Mon, 28 Oct 2024 22:37:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30A166B0099; Mon, 28 Oct 2024 18:37:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 291B66B009E; Mon, 28 Oct 2024 18:37:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 133EA6B00A0; Mon, 28 Oct 2024 18:37:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E0C496B0099 for ; Mon, 28 Oct 2024 18:37:17 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id ACFD2A06B9 for ; Mon, 28 Oct 2024 22:37:17 +0000 (UTC) X-FDA: 82724471718.20.658FB87 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf22.hostedemail.com (Postfix) with ESMTP id B1892C000F for ; Mon, 28 Oct 2024 22:36:46 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=bLb3h18w; spf=pass (imf22.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=1730154981; 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=txZ5FjWCswLrn5R55z+wYaLbR9OTGv+7YeGcXUxb8wU=; b=mVegIARHgKvok2COJr0FspCjOum50YpP2KCen43BSycZ76PiDiwVZVTuu3pI4qhUXzCos6 gGxYLmqwRe1NCDKDmsCwGwKSZ3hUQF1FCcdMH7rV7/12Rl0GsC21eehLdk4e8BSkxc8kD7 vF34WMn/Uf2wZ+G7dQPaRTSFJCMxBKY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=bLb3h18w; spf=pass (imf22.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=1730154981; a=rsa-sha256; cv=none; b=1nUBWJD2LWwL7wGmyrgnzhB3ZAdY1uHA9NBjUyLQwfTDyWhKmnaXg1lTnpP86Fi6jEQcAB b/T/8Vscb6P2rlwxzUSPr1SOjLot49RvWe4O8tNnGrcdAjkYpqqLhv2OWJk2GxPkl71jFK UPemlo1h0zpDH6u7Uz8Vtsf8Ao3sJOM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1730155035; bh=txZ5FjWCswLrn5R55z+wYaLbR9OTGv+7YeGcXUxb8wU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bLb3h18wgG+pWjMR3LBhLa5H3cOjWb4ZEVRL0zBy/sDAOIROkHifR2SEggXt+FZl9 IJ6DUCoQqHVdne3vCbwAt0YMT3brstrJrt/p0B9q+GH9jj3rhbTv5sbev7GL84AvkN SrUNrq5CrpzNSxczBYaIuVFfdWcGptTYeYHizNVQ= Received: by gentwo.org (Postfix, from userid 1003) id 3012340262; Mon, 28 Oct 2024 15:37:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 2EFAE401C8; Mon, 28 Oct 2024 15:37:15 -0700 (PDT) Date: Mon, 28 Oct 2024 15:37:15 -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: <20241028094618.GL9767@noisy.programming.kicks-ass.net> Message-ID: <50dc2133-5f43-3a02-38a9-234e8acb5b8c@gentwo.org> References: <20241025090347.244183920@infradead.org> <20241025093944.485691531@infradead.org> <20241028094618.GL9767@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Stat-Signature: dqgffprh43fp9jhpcxmt6xxk1rycawti X-Rspamd-Queue-Id: B1892C000F X-Rspamd-Server: rspam11 X-HE-Tag: 1730155006-496116 X-HE-Meta: U2FsdGVkX1+xFFEHcSek84fVSzFsHc68Cef5OiTCHaHad9IHioOEuBNdy9XsYi6A8CdA/DcNQEzrylDnEvMy/Oi4exrNnmpLwTcfpmFSWkrddpNEabX3sR5zn5lq+yZEIiW9Ce7XGQZS7G3uYk9sdhxxzYxtrEDjo7pkDN0iClF1YSEzJEkya/vCj4TtqhC4v9ZGvcnK8P5G0j9+HIYTfKFyZmB6ZqF5ghN/Q9LSa0xDTQZb77PRWATUmiDwcvMWHCQNCDajkXXNEU/l3fVB14tAWHVu93FVUxEmZCxxkFNxlWNo6ZbxV7nD+Jg5BJLerhofL1gzsQ9FRzJx7UjxJcUNMc03Vrfo6HxcAzbD9xqf92BrvdxkW71Lndjdj8XC+q/mfRsPUAHNJQ5vXYB40FcJ1nDGBaEZ+b6UgaOQD0b5Baga6t7JNfmkUz1IzamwNlxrxSw7G5RdX1DmfjBoJAXhVBd9oHTSWsK4z0WENdZDwE9PrUW69U3v/ByCJBzZwdVX7olo/0Kc1a0w+mYT7kdHulz+AwMgh6fIvPXDHmJ2lWwtCuZSLMNZ6VObbO+E1YvXlJt53jHJZIn90XuH1YgOD3Wg33CyOnM0VlBvqY7s6V1EJqGqt58QL6FjS/J4s4tmC+AmZJlZHwnPVX6okXFwlK0OMxUVt0GJ7mNY1bz6kBXNvifxjd0SmZseyZ6DrxzawSEn2wJOfZpnfw/D+PPO/YjYPni0XHbW61XMw8vaBBrBPWjjLNKtjssZv4KL5xTV0/+E3GlbHYB1040j3hH8OwSr4aPJXN16uleHXU2ygVT8b5CtkNL5iIZ0kjHaLynhpiGJBjxwt1KGMxGbKOWeMC7kCTBcJ6jkXR/7ej2g4s2yZsouUVpibCtz7ky8yjlV8W+inJcFTnI/CuLAg8APhya3HC1onO8jjlilK3R+7CSfyQ4nnnpd3FwOvPlfJ2xy6VPW5KLShlWn+jW KJ9ufd7L mH9tARsdLBOoUGnd7+LsFXYtr8SZe3+wpzCBPH9JZdaLB4xbsUQoIO4eIB19H6C98Lq1GEPWV6shO/17zBPkusd2lZxzXH9Kc31sT9SAyzLzy7GXpu/KMIUTuRpEePU3pU5KDVHBkCDXc+dGu6Aa7liRlHkML530B2WAxxi4tGxZ1wycExF5ExSL84+y24WPBvfj/PiZDlI9uFHRoc8g810+J201/kn72yyzZ8X7psk89SD9HtNAOm2rB/ZAprUmExTOe8DtLNZxXoWw= 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 Mon, 28 Oct 2024, Peter Zijlstra wrote: > Using get_task_policy() seems very dangerous to me. It is explicitly > possible for different tasks in a process to have different policies, > which means (private) futexes would fail to work correctly. > > We need something that is process wide consistent -- like the vma > policies. Except at current, those are to expensive to readily access. The vma policies are bound to addresses that in turn yields address space wide validity. However, different threads may run on processes on different nodes and therefore having different numa nodes close to them etc.