diff options
author | John Stultz <jstultz@google.com> | 2024-07-08 23:08:27 -0700 |
---|---|---|
committer | Peter Zijlstra <peterz@infradead.org> | 2024-07-09 13:26:26 +0200 |
commit | e81859fe64ad42dccefe134d1696e0635f78d763 (patch) | |
tree | 917ad09aae5effc8d7292ae0b0d729a891033988 /drivers/cpufreq/Kconfig.x86 | |
parent | 9bc2ff871f00437ad2f10c1eceff51aaa72b478f (diff) |
locking/rwsem: Add __always_inline annotation to __down_write_common() and inlined callers
Apparently despite it being marked inline, the compiler
may not inline __down_write_common() which makes it difficult
to identify the cause of lock contention, as the wchan of the
blocked function will always be listed as __down_write_common().
So add __always_inline annotation to the common function (as
well as the inlined helper callers) to force it to be inlined
so a more useful blocking function will be listed (via wchan).
This mirrors commit 92cc5d00a431 ("locking/rwsem: Add
__always_inline annotation to __down_read_common() and inlined
callers") which did the same for __down_read_common.
I sort of worry that I'm playing wack-a-mole here, and talking
with compiler people, they tell me inline means nothing, which
makes me want to cry a little. So I'm wondering if we need to
replace all the inlines with __always_inline, or remove them
because either we mean something by it, or not.
Fixes: c995e638ccbb ("locking/rwsem: Fold __down_{read,write}*()")
Reported-by: Tim Murray <timmurray@google.com>
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Link: https://lkml.kernel.org/r/20240709060831.495366-1-jstultz@google.com
Diffstat (limited to 'drivers/cpufreq/Kconfig.x86')
0 files changed, 0 insertions, 0 deletions