From: Waiman Long <longman@redhat.com>
To: bibo mao <maobibo@loongson.cn>,
guoren@kernel.org, David.Laight@ACULAB.COM, will@kernel.org,
peterz@infradead.org, mingo@redhat.com
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org,
Guo Ren <guoren@linux.alibaba.com>
Subject: Re: [PATCH V2] asm-generic: ticket-lock: Optimize arch_spin_value_unlocked
Date: Mon, 31 Jul 2023 21:59:33 -0400 [thread overview]
Message-ID: <f34ddf7f-3ed9-6118-8106-eb9df110c44c@redhat.com> (raw)
In-Reply-To: <2437ac29-29f0-34f9-b7cb-f0e294db7dc6@loongson.cn>
On 7/31/23 21:37, bibo mao wrote:
>
> 在 2023/7/31 23:16, Waiman Long 写道:
>> On 7/30/23 22:33, guoren@kernel.org wrote:
>>> From: Guo Ren <guoren@linux.alibaba.com>
>>>
>>> The arch_spin_value_unlocked would cause an unnecessary memory
>>> access to the contended value. Although it won't cause a significant
>>> performance gap in most architectures, the arch_spin_value_unlocked
>>> argument contains enough information. Thus, remove unnecessary
>>> atomic_read in arch_spin_value_unlocked().
>>>
>>> The caller of arch_spin_value_unlocked() could benefit from this
>>> change. Currently, the only caller is lockref.
>>>
>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>> Cc: Waiman Long <longman@redhat.com>
>>> Cc: David Laight <David.Laight@ACULAB.COM>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
>>> ---
>>> Changelog
>>> V2:
>>> - Fixup commit log with Waiman advice.
>>> - Add Waiman comment in the commit msg.
>>> ---
>>> include/asm-generic/spinlock.h | 16 +++++++++-------
>>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/include/asm-generic/spinlock.h b/include/asm-generic/spinlock.h
>>> index fdfebcb050f4..90803a826ba0 100644
>>> --- a/include/asm-generic/spinlock.h
>>> +++ b/include/asm-generic/spinlock.h
>>> @@ -68,11 +68,18 @@ static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
>>> smp_store_release(ptr, (u16)val + 1);
>>> }
>>> +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
>>> +{
>>> + u32 val = lock.counter;
>>> +
>>> + return ((val >> 16) == (val & 0xffff));
>>> +}
>>> +
>>> static __always_inline int arch_spin_is_locked(arch_spinlock_t *lock)
>>> {
>>> - u32 val = atomic_read(lock);
>>> + arch_spinlock_t val = READ_ONCE(*lock);
>>> - return ((val >> 16) != (val & 0xffff));
>>> + return !arch_spin_value_unlocked(val);
>>> }
>>> static __always_inline int arch_spin_is_contended(arch_spinlock_t *lock)
>>> @@ -82,11 +89,6 @@ static __always_inline int arch_spin_is_contended(arch_spinlock_t *lock)
>>> return (s16)((val >> 16) - (val & 0xffff)) > 1;
>>> }
>>> -static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
>>> -{
>>> - return !arch_spin_is_locked(&lock);
>>> -}
>>> -
>>> #include <asm/qrwlock.h>
>>> #endif /* __ASM_GENERIC_SPINLOCK_H */
>> I am fine with the current change. However, modern optimizing compiler should be able to avoid the redundant memory read anyway. So this patch may not have an impact from the performance point of view.
> arch_spin_value_unlocked is called with lockref like this:
>
> #define CMPXCHG_LOOP(CODE, SUCCESS) do { \
> int retry = 100; \
> struct lockref old; \
> BUILD_BUG_ON(sizeof(old) != 8); \
> old.lock_count = READ_ONCE(lockref->lock_count); \
> while (likely(arch_spin_value_unlocked(old.lock.rlock.raw_lock))) { \
>
> With modern optimizing compiler, Is it possible that old value of
> old.lock.rlock.raw_lock is cached in register, despite that try_cmpxchg64_relaxed
> modifies the memory of old.lock_count with new value?
What I meant is that the call to arch_spin_value_unlocked() as it is
today will not generate 2 memory reads of the same location with or
without the patch. Of course, a new memory read will be needed after a
failed cmpxchg().
Cheers,
Longman
next prev parent reply other threads:[~2023-08-01 2:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 2:33 guoren
2023-07-31 9:56 ` Will Deacon
2023-07-31 11:27 ` bibo mao
2023-07-31 15:16 ` Waiman Long
2023-08-01 1:37 ` bibo mao
2023-08-01 1:59 ` Waiman Long [this message]
2023-08-01 4:05 ` bibo mao
2023-08-07 18:36 ` Mateusz Guzik
2023-08-08 3:29 ` Guo Ren
2023-08-08 8:02 ` Mateusz Guzik
2023-08-29 7:37 ` Guo Ren
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=f34ddf7f-3ed9-6118-8106-eb9df110c44c@redhat.com \
--to=longman@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maobibo@loongson.cn \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.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®