From: Vlastimil Babka <vbabka@suse.cz>
To: Michael Larabel <Michael@phoronix.com>,
Shakeel Butt <shakeel.butt@linux.dev>
Cc: Dave Airlie <airlied@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Sebastian Sewior <bigeasy@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 6.15-rc3
Date: Wed, 23 Apr 2025 10:42:03 +0200 [thread overview]
Message-ID: <27d55aab-c2d8-4edf-bab5-91a04b8383c5@suse.cz> (raw)
In-Reply-To: <896a67ec-9f48-4137-9d34-4bb16861e284@phoronix.com>
On 4/23/25 02:54, Michael Larabel wrote:
> On 4/22/25 7:12 PM, Shakeel Butt wrote:
>> Ccing Michael
>>
>> On Tue, Apr 22, 2025 at 04:37:59PM -0700, Alexei Starovoitov wrote:
>>> On Tue, Apr 22, 2025 at 4:01 PM Dave Airlie <airlied@gmail.com> wrote:
>>>>> Alexei Starovoitov (2):
>>>>> locking/local_lock, mm: replace localtry_ helpers with
>>>>> local_trylock_t type
>>>> This seems to have upset some phoronix nginx workload
>>>> https://www.phoronix.com/review/linux-615-nginx-regression/2
>>> 3x regression? wow.
>>> Thanks for heads up.
>>> I'm staring at the patch and don't see it.
>>> Adding more experts.
>> Hi Michael,
>>
>> Can you please share a bit more on your nginx workload and how can we
>> reproduce locally? In the mean time, I can try netperf locally to
>> reproduce.
>>
>> I do have some followup optimizations [1, 2] which hopefully are aimed
>> for next release but we can try those as well.
>>
>> [1] https://lkml.kernel.org/r/20250416180229.2902751-1-shakeel.butt@linux.dev
>> [2] https://lkml.kernel.org/r/20250410025752.92159-1-shakeel.butt@linux.dev
>>
>> thanks,
>> Shakeel
>
> The Nginx test case is a fairly stock Nginx build measuring HTTPS
> throughput for serving some static web page with Wrk used as the
> stressor, all on the same host for stressing just the local host. All of
> the assets and execution scripts used for that Nginx test in raw form
> are here -
> https://openbenchmarking.org/innhold/c7b555063f5732b4f1bb08444e258984d1dbb94b
> Let me know if any problems reproducing, etc.
>
> Thanks, I can try out those patches tomorrow. At the moment on that same
> server currently running through some of the other workloads I also
> found regressed on Linux 6.15 GIt to see if attributed to same commit or
> not.
Hi, please try the following patch. I also realized I left you out of my previous
replies leading to it, due to replying to an earlier mail of the thread:
https://lore.kernel.org/all/0981c1fe-05d2-4bab-a0a4-6dc5666d98d7@suse.cz/
Thanks,
Vlastimil
----8<----
From: Vlastimil Babka <vbabka@suse.cz>
Date: Wed, 23 Apr 2025 10:21:29 +0200
Subject: [PATCH] locking/local_lock: fix _Generic() matching of
local_trylock_t
Michael Larabel reported [1] a nginx performance regression in v6.15-rc3 and
bisected it to commit 51339d99c013 ("locking/local_lock, mm: replace
localtry_ helpers with local_trylock_t type")
The problem is the _Generic() usage with a default association that
masks the fact that "local_trylock_t *" association is not being
selected as expected. Replacing the default with the only other expected
type "local_lock_t *" reveals the underlying problem:
./include/linux/local_lock_internal.h:174:26: error: ‘_Generic’ selector of
type ‘__seg_gs local_lock_t *’ is not compatible with any association
The local_locki's are part of __percpu structures and thus the __percpu
attribute is needed to associate the type properly. Add the attribute
and keep the default replaced to turn any further mismatches into
compile errors.
The failure to recognize local_try_lock_t in __local_lock_release()
means that a local_trylock[_irqsave]() operation will set tl->acquired
to 1 (there's no _Generic() part in the trylock code), but then
local_unlock[_irqrestore]() will not set tl->acquired back to 0, so
further trylock operations will always fail on the same cpu+lock, while
non-trylock operations continue to work - a lockdep_assert() is also
not being executed in the _Generic() part of local_lock() code.
This means consume_stock() and refill_stock() operations will fail
deterministically, resulting in taking the slow paths and worse
performance.
Fixes: 51339d99c013 ("locking/local_lock, mm: replace localtry_ helpers with local_trylock_t type")
Reported-by: Michael Larabel <Michael@phoronix.com>
Closes: https://www.phoronix.com/review/linux-615-nginx-regression/2 [1]
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
include/linux/local_lock_internal.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/local_lock_internal.h b/include/linux/local_lock_internal.h
index bf2bf40d7b18..8d5ac16a9b17 100644
--- a/include/linux/local_lock_internal.h
+++ b/include/linux/local_lock_internal.h
@@ -102,11 +102,11 @@ do { \
l = (local_lock_t *)this_cpu_ptr(lock); \
tl = (local_trylock_t *)l; \
_Generic((lock), \
- local_trylock_t *: ({ \
+ __percpu local_trylock_t *: ({ \
lockdep_assert(tl->acquired == 0); \
WRITE_ONCE(tl->acquired, 1); \
}), \
- default:(void)0); \
+ __percpu local_lock_t *: (void)0); \
local_lock_acquire(l); \
} while (0)
@@ -171,11 +171,11 @@ do { \
tl = (local_trylock_t *)l; \
local_lock_release(l); \
_Generic((lock), \
- local_trylock_t *: ({ \
+ __percpu local_trylock_t *: ({ \
lockdep_assert(tl->acquired == 1); \
WRITE_ONCE(tl->acquired, 0); \
}), \
- default:(void)0); \
+ __percpu local_lock_t *: (void)0); \
} while (0)
#define __local_unlock(lock) \
--
2.49.0
next prev parent reply other threads:[~2025-04-23 8:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-20 21:01 Linus Torvalds
2025-04-20 23:03 ` Linus Torvalds
2025-04-21 13:20 ` Guenter Roeck
2025-04-22 23:01 ` Dave Airlie
2025-04-22 23:37 ` Alexei Starovoitov
2025-04-23 0:12 ` Shakeel Butt
2025-04-23 0:54 ` Michael Larabel
2025-04-23 8:42 ` Vlastimil Babka [this message]
2025-04-23 13:57 ` Michael Larabel
2025-04-23 15:41 ` Alexei Starovoitov
2025-04-23 16:05 ` Linus Torvalds
2025-04-23 7:14 ` Vlastimil Babka
2025-04-23 8:03 ` Vlastimil Babka
2025-04-23 8:08 ` Vlastimil Babka
2025-04-23 14:38 ` Michael Larabel
2025-04-23 15:06 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27d55aab-c2d8-4edf-bab5-91a04b8383c5@suse.cz \
--to=vbabka@suse.cz \
--cc=Michael@phoronix.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®