From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 331101F44D for ; Fri, 26 Apr 2024 10:15:23 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=desiato.20200630 header.b=rQRPqrFJ; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 68D213846079 for ; Fri, 26 Apr 2024 10:15:22 +0000 (GMT) Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by sourceware.org (Postfix) with ESMTPS id 68A503858C42 for ; Fri, 26 Apr 2024 10:14:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68A503858C42 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=infradead.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 68A503858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:8b0:10b:1:d65d:64ff:fe57:4e05 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714126500; cv=none; b=iLH8xMvybZ2p/y3NKYQWEVSeV/49WMn50OJzKRuMae47cBC1e1oDz9/Jv2LRArmOADyoQfYkzYX+M/JzOvSDCHxDG82tXUF9l0jbaOcB1dOscNP1QftiGWzDJe3zGOiI3GXJ3VvKRVBc/m81+PPoJEo+ZaL5GusH6tIWWU4r9II= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714126500; c=relaxed/simple; bh=ALcIRln45Y/G2JaG5UVvoiGMeRWE02AZbGsl22MTiPw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wqZ1ZQpmrBeZRZWPa7AjjEDrhr3Yk6cKqXzPfAateRj9bgahFqAdR6aU3w9/vB8fKrdj8/LUIvSwE+XSP6bVilo6gjNzsBIG0HCSkGz5Kfj4+7hDfbFif9RPlUpUH84RwMkXO0KgS81l4TeI9jZKs8ctfrfjTvh6WSsDqPXOXb8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=ryVjswdoVqQB3NDQl33vADKSu7VWuONlL8jqOs+n9Sc=; b=rQRPqrFJRAj/wPN4+4jEVy5+g6 DkVhX3SxFUbWNnMCLhscqUhlHshGMr3IIXxvs1pePUypW+E/rp8SF6BTwgkeBbwi+Co0Pyoka4lG/ FUuaWXY8IsgUZynPjdIb+JmW1g9RmkcbF9V4hzEPJ5mCuAOFTWVupuig5rXp/EoHP/jeFBKNNqT9L C7b5b/b2wgVP8QbeuwNoNCa+ElthXH3shJKTuIruKaTJuIBTZwIrkMSyzay6LytNickkC4QhVbcgK NMQdK4Wfv5PzKS02/chz/QDtiA/MdrYTej0+wjIhkRghMu0qsTWHMderpRfW7qdfmof+oM3xwfIru 9l4U4qKQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.97.1 #2 (Red Hat Linux)) id 1s0IbH-0000000FHLR-0ngO; Fri, 26 Apr 2024 10:14:39 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C6DD63003EA; Fri, 26 Apr 2024 12:14:38 +0200 (CEST) Date: Fri, 26 Apr 2024 12:14:38 +0200 From: Peter Zijlstra To: Florian Weimer Cc: =?iso-8859-1?Q?Andr=E9?= Almeida , Mathieu Desnoyers , Thomas Gleixner , linux-kernel@vger.kernel.org, "Paul E . McKenney" , Boqun Feng , "H . Peter Anvin" , Paul Turner , linux-api@vger.kernel.org, Christian Brauner , David.Laight@aculab.com, carlos@redhat.com, Peter Oskolkov , Alexander Mikhalitsyn , Chris Kennelly , Ingo Molnar , Darren Hart , Davidlohr Bueso , libc-alpha@sourceware.org, Steven Rostedt , Jonathan Corbet , Noah Goldstein , Daniel Colascione , longman@redhat.com, kernel-dev@igalia.com Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation Message-ID: <20240426101438.GA39183@noisy.programming.kicks-ass.net> References: <20240425204332.221162-1-andrealmeid@igalia.com> <875xw44fxk.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <875xw44fxk.fsf@oldenburg.str.redhat.com> X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org On Fri, Apr 26, 2024 at 11:43:51AM +0200, Florian Weimer wrote: > * André Almeida: > > > With FUTEX2_SPIN flag set during a futex_wait(), the futex value is > > expected to be the PID of the lock owner. Then, the kernel gets the > > task_struct of the corresponding PID, and checks if it's running. It > > spins until the futex is awaken, the task is scheduled out or if a > > timeout happens. If the lock owner is scheduled out at any time, then > > the syscall follows the normal path of sleeping as usual. > > PID or TID? TID, just like PI_LOCK I would presume. > I think we'd like to have at least one, possibly more, bits for free > use, so the kernel ID comparison should at least mask off the MSB, > possibly more. Yeah, it should be using FUTEX_TID_MASK -- just like PI_LOCK :-) I suppose the question is if this thing should then also imply FUTEX_WAITERS or not.