From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=216.40.44.15 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794073049; b=MdJM0AoJbwJcbf71zUpwWuWxpE+EuF/WSVlplY1WLjvhDRpyTS6s7lWqUQo8RxiwG+Yr oY1DZjzllDmHtfNGxhf6cDdFQbqiMItr8zYHteBTgE7wwkvn2vv38XUTNXxCAQ4BDtVdZ 1GJYgIfz2ULdb4MEIr2RqX/12gLw1QLznes10hRFtIDb8d2Xff2e0qpE8ebNVmvZY/aZ+ qdrJa0Sm9CuAVymhKL5FokbFxr4vr00KhXAQnmydTOqT6Y1OeUhOvxOawJFVwypAWcW62 2cqoSz3tEvQuN0+n7/jaSeqqLmgLOEK5AWb8xEWPYlj8I75smRqG4lEYN5W7zjZJpYA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794073049; h=DMARC-Filter:Received:Received:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding:X-Rspamd-Queue-Id:X-Rspamd-Server: X-Stat-Signature:X-Spam-Status:X-Session-Marker:X-Session-ID: DKIM-Signature:X-HE-Tag:X-HE-Meta; bh=jA1Z4duQiQzeKq317JC2yso+OfINr1SzmCCDBHpydj0=; b=jvQKW3N0pC3vl/cPao7wqX1Q8Weqc0F5HdpXgkscoyLIq2726zRXCCbQ/OLwsauEphzp 2CGjYrUMwboebbzukPJZrHPDt0t2GqF+oljwiBn5FElKMdX3/4Li0a2Ni4OVo42VnP7r9 PnLa2Z2whulfbxwu3pflVk2jpaXde5AYfE+AJwmo8hfX6W1J91BKn8r4HR2vy3B/FkEz4 lc8QsfwIehTmAkz2HL9jpBVTw1ZdxSUdn76bbeamSZINeJ7ZDq6F+VcC0myQ76ZsjEbRl pXWP1sCwKXWOcqgXm/wrRphHJ7aQR3qJyMbn0Gx2NdnNBPOlsZeaAtECxB9NImsncmg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; dkim=pass header.d=goodmis.org header.i=@goodmis.org header.a=rsa-sha256 header.s=dkim1 header.b=QHJOEINu; arc=none smtp.remote-ip=216.40.44.15 Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B195606A32C for ; Sat, 7 Nov 2026 17:37:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 0B195606A32C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=goodmis.org header.i=@goodmis.org header.a=rsa-sha256 header.s=dkim1 header.b=QHJOEINu Received: from omf11.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 86C801C3AE5; Sat, 7 Nov 2026 17:37:19 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf11.hostedemail.com (Postfix) with ESMTPA id 535692002C; Sat, 7 Nov 2026 17:36:58 +0000 (UTC) Date: Sat, 7 Nov 2026 12:36:42 -0500 From: Steven Rostedt To: Mathieu Desnoyers Cc: Peter Zijlstra , tglx@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, will@kernel.org, boqun@kernel.org, longman@redhat.com, bigeasy@linutronix.de, clrkwllms@kernel.org, dvhart@infradead.org, dave@stgolabs.net, andrealmeid@igalia.com, shuah@kernel.org, juri.lelli@redhat.com, linux-rt-devel@lists.linux.dev, linux-kselftest@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/5] locking/rtmutex: Stop spinning on the owner when the waiter is woken Message-ID: <20261107123642.149677cf@fedora> In-Reply-To: References: <20261106235931.1478800-1-mathieu.desnoyers@efficios.com> <20261106235931.1478800-2-mathieu.desnoyers@efficios.com> <20261107002927.3cbad7ff@fedora> <20261107104329.GA2668564@noisy.programming.kicks-ass.net> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) X-Mailing-List: linux-rt-devel@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 535692002C X-Rspamd-Server: rspamout08 X-Stat-Signature: m44kupjn78amr5iba158yzo71aerdhcm X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX195nEAbX1ye5HLf4TYsMhI2TyWK0f81IaE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=goodmis.org; h=date:from:to:cc:subject:message-id:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=dkim1; bh=jA1Z4duQiQzeKq317JC2yso+OfINr1SzmCCDBHpydj0=; b=QHJOEINuZLikmXVnkZT2L1ruJL/sFiyj1a7fbmNisUYPM3FED5UQaDWWBORf0uFWwrdV+MSQvl3GNH3g8/YiS2DTRupvspu8y8ro5C+eGzlCZIyVNXhDeXc44nGtcTwk00tHGTLiRum5o/wuaeGIUUQHOStCmkvQsjjCbVzmWuA= X-HE-Tag: 1794073018-50227 X-HE-Meta: U2FsdGVkX1/xkZuEMEbBCRfnErlHYkRLRDuQ4GKd9JI66MgGk/9EtQjOr/4EcRkcQOmN7p7qTwDBZxQqLm4BRwFmhmB9b4FT7qkkG/sM2/a/lPmoftsEN/kGVVCJbP+oMtphFphXzojKGJXDoLj7973AVD34omJ6wjmlwbP7MNKbExqBzs0oifpfMCDA5FVYn1bwahkR2vCtgteuYTycxiab2tDqi1C3jnBKVa3FWckqqUst1nKjCoFXLjeCFbuaIcALKm2/gOo7lB6qmJiGE5+o5wL3iio+Gr9V6QpxtRAQCR0nLXBc00qzgheVeJuVnuguVSM304hz/NPMKas+Vb2qsxx5UeuMKzPJ0tQ0jO7+eAxCRaeVpEa1zm7Nq6bRRB8MX3GIgUJ0MPL1PjHCTqzV34xxNRpvXpf+I1wuKcH8PTU1dokdby+pxg9PhWaszNLnhPaeC4uIiIqTG7UIUQ== On Sat, 7 Nov 2026 07:29:54 -0500 Mathieu Desnoyers wrote: > >> > >> The above is very verbose. Are you starting to use AI? ;-) > > I definitely am, as stated in the cover letter. :-) I skipped that part of the cover letter. The first patch touches my code (it has my commit as fixes) so I just jumped straight to that one. > > > > > He definitely is. I can't read the above, its word soup. Part of using > > AI is making sure the Changelog is actually readable. This is not. > > Feedback on the commit message wording is welcome, I'll try to improve > things for next iterations. Is the following easier to parse ? I fed > Peter's and my own criticism to Claude and got it to rewrite the entire > thing (and keep those learnings for next time): > > locking/rtmutex: Stop spinning on the owner when the waiter is woken > > The top waiter of an rt_mutex sets its sleep state. Then it spins in > rtmutex_spin_on_owner() as long as the owner is running. A wakeup sets > the waiter back to TASK_RUNNING. The spin loop does not check for this. > So a timeout or a signal is only handled when the owner blocks, or when > the waiter has to reschedule: > > CPU 0 (waiter) CPU 1 (owner) > > pthread_mutex_lock() > takes the PI futex > spins in userspace > pthread_mutex_timedlock(1ms) > futex_lock_pi() > rt_mutex_wait_proxy_lock() > set_current_state(TASK_INTERRUPTIBLE) > rt_mutex_slowlock_block() > rtmutex_spin_on_owner() > hrtimer_wakeup() > wake_up_process(waiter) > __state = TASK_RUNNING > owner_on_cpu(owner): true > need_resched(): false > keeps spinning still spins in userspace > > The owner of a PI futex is a user task. It can run for a long time. > With an owner spinning in userspace, a 1ms pthread_mutex_timedlock() > returns up to 1.4s late. A signal to the waiter is delayed in the same > way. > > With PREEMPT_RT, a ww_mutex wound is missed too. Two contexts take two > ww_mutexes in opposite order, on two CPUs. They spin on each other for > up to a second. > > Fix this by also stopping the spin when the waiter is TASK_RUNNING. The > slowpath then handles the timeout, the signal or the wound, as it does > after schedule(). > > rtlock waiters are not affected. Only the lock handoff wakes them from > TASK_RTLOCK_WAIT. > > With this patch, the 1ms timed lock returns after about 1ms. The > ww_mutex ABBA resolves in microseconds. PI mutex throughput is > unchanged. The futex and ww_mutex selftests added later in this series > cover both cases. Still way too verbose for the fix. It makes it sound more complicated than it is. locking/rtmutex: Stop spinning on the owner when the waiter is woken The top waiter of an rt_mutex sets its sleep state. Then it spins in rtmutex_spin_on_owner() as long as the owner is running. A wakeup sets the waiter back to TASK_RUNNING. The spin loop does not check for this. So a timeout or a signal is only handled when the owner blocks, or when the waiter has to reschedule. The rtmutex_spin_on_owner() is just an optimization with the idea that if the owner is still running on a CPU, it will likely release it soon. If the owner gets preempted or schedules out on its own, the spinning will stop and the waiter will sleep. This came from PREEMPT_RT adaptive spinning for rt_spin_locks that allowed them to behave more like normal spin locks and speed up PREEMPT_RT performance. The problem is that when this was implemented for futex and normal mutexes it did not account for timeouts or other mechanisms where the owner releasing the lock wasn't the only way for the spinning task to exit the mutex acquire. The spinning currently does not account for anything else but the lock being released or the owner sleeping. Luckily, when the spinning task needs to exit the mutex lock code, it's state is set to TASK_RUNNING. By having the spin check the spinning task's state to see if it switches to running, it can exit the spin appropriately. How about something like the above? -- Steve > > Fixes: 992caf7f1724 ("locking/rtmutex: Add adaptive spinwait mechanism") > Cc: stable@vger.kernel.org > Reviewed-by: Steven Rostedt > Signed-off-by: Mathieu Desnoyers >