Received-SPF: pass (google.com: domain of linux-kernel+bounces-159808-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Florian Weimer <fweimer@redhat.com>
To: =?utf-8?Q?Andr=C3=A9?= Almeida <andrealmeid@igalia.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,  Peter Zijlstra
 <peterz@infradead.org>,  Thomas Gleixner <tglx@linutronix.de>,
  linux-kernel@vger.kernel.org,  "Paul E . McKenney" <paulmck@kernel.org>,
  "Boqun Feng" <boqun.feng@gmail.com>,  "H . Peter Anvin" <hpa@zytor.com>,
  "Paul Turner" <pjt@google.com>,  linux-api@vger.kernel.org,  "Christian
 Brauner" <brauner@kernel.org>,  David.Laight@ACULAB.COM,
  carlos@redhat.com,  "Peter Oskolkov" <posk@posk.io>,  "Alexander
 Mikhalitsyn" <alexander@mihalicyn.com>,  "Chris Kennelly"
 <ckennelly@google.com>,  "Ingo Molnar" <mingo@redhat.com>,  "Darren Hart"
 <dvhart@infradead.org>,  "Davidlohr Bueso" <dave@stgolabs.net>,
  libc-alpha@sourceware.org,  "Steven Rostedt" <rostedt@goodmis.org>,
  "Jonathan Corbet" <corbet@lwn.net>,  "Noah Goldstein"
 <goldstein.w.n@gmail.com>,  "Daniel Colascione" <dancol@google.com>,
  longman@redhat.com,  kernel-dev@igalia.com
Subject: Re: [RFC PATCH 0/1] Add FUTEX_SPIN operation
In-Reply-To: <20240425204332.221162-1-andrealmeid@igalia.com>
 (=?utf-8?Q?=22Andr=C3=A9?=
	Almeida"'s message of "Thu, 25 Apr 2024 17:43:31 -0300")
References: <20240425204332.221162-1-andrealmeid@igalia.com>
Date: Fri, 26 Apr 2024 11:43:51 +0200
Message-ID: <875xw44fxk.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

* Andr=C3=A9 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?

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.

I haven't really thought about the proposed locking protocol, sorry.

Thanks,
Florian