From: Ingo Molnar <mingo@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: David Laight <David.Laight@aculab.com>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
"'peterz@infradead.org'" <peterz@infradead.org>,
"'mingo@redhat.com'" <mingo@redhat.com>,
"'will@kernel.org'" <will@kernel.org>,
"'boqun.feng@gmail.com'" <boqun.feng@gmail.com>,
'Linus Torvalds' <torvalds@linux-foundation.org>,
"'xinhui.pan@linux.vnet.ibm.com'" <xinhui.pan@linux.vnet.ibm.com>,
"'virtualization@lists.linux-foundation.org'"
<virtualization@lists.linux-foundation.org>,
'Zeng Heng' <zengheng4@huawei.com>
Subject: Re: [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data accesses.
Date: Sat, 30 Dec 2023 12:09:20 +0100 [thread overview]
Message-ID: <ZY/6YCNJ7tSCmiGo@gmail.com> (raw)
In-Reply-To: <346c40b5-686f-461e-a1e3-9f255418efb2@redhat.com>
* Waiman Long <longman@redhat.com> wrote:
> On 12/29/23 15:57, David Laight wrote:
> > this_cpu_ptr() is rather more expensive than raw_cpu_read() since
> > the latter can use an 'offset from register' (%gs for x86-84).
> >
> > Add a 'self' field to 'struct optimistic_spin_node' that can be
> > read with raw_cpu_read(), initialise on first call.
> >
> > Signed-off-by: David Laight <david.laight@aculab.com>
> > ---
> > kernel/locking/osq_lock.c | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> > index 9bb3a077ba92..b60b0add0161 100644
> > --- a/kernel/locking/osq_lock.c
> > +++ b/kernel/locking/osq_lock.c
> > @@ -13,7 +13,7 @@
> > */
> > struct optimistic_spin_node {
> > - struct optimistic_spin_node *next, *prev;
> > + struct optimistic_spin_node *self, *next, *prev;
> > int locked; /* 1 if lock acquired */
> > int cpu; /* encoded CPU # + 1 value */
> > };
> > @@ -93,12 +93,16 @@ osq_wait_next(struct optimistic_spin_queue *lock,
> > bool osq_lock(struct optimistic_spin_queue *lock)
> > {
> > - struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
> > + struct optimistic_spin_node *node = raw_cpu_read(osq_node.self);
>
> My gcc 11 compiler produces the following x86-64 code:
>
> 92 struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
> 0x0000000000000029 <+25>: mov %rcx,%rdx
> 0x000000000000002c <+28>: add %gs:0x0(%rip),%rdx # 0x34
> <osq_lock+36>
>
> Which looks pretty optimized for me. Maybe older compiler may generate more
> complex code. However, I do have some doubt as to the benefit of this patch
> at the expense of making the code a bit more complex.
GCC-11 is plenty of a look-back window in terms of compiler efficiency:
latest enterprise distros use GCC-11 or newer, while recent desktop
distros use GCC-13. Anything older won't matter, because no major
distribution is going to use new kernels with old compilers.
Thanks,
Ingo
next prev parent reply other threads:[~2023-12-30 11:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-29 20:51 [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code David Laight
2023-12-29 20:53 ` [PATCH next 1/5] locking/osq_lock: Move the definition of optimistic_spin_node into osf_lock.c David Laight
2023-12-30 1:59 ` Waiman Long
2023-12-29 20:54 ` [PATCH next 2/5] locking/osq_lock: Avoid dirtying the local cpu's 'node' in the osq_lock() fast path David Laight
2023-12-29 20:56 ` [PATCH next 3/5] locking/osq_lock: Clarify osq_wait_next() David Laight
2023-12-29 22:54 ` Linus Torvalds
2023-12-30 2:54 ` Waiman Long
2023-12-29 20:57 ` [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data accesses David Laight
2023-12-30 3:08 ` Waiman Long
2023-12-30 11:09 ` Ingo Molnar [this message]
2023-12-30 11:35 ` David Laight
2023-12-31 3:04 ` Waiman Long
2023-12-31 10:36 ` David Laight
2023-12-30 20:37 ` Ingo Molnar
2023-12-30 22:47 ` David Laight
2023-12-30 20:41 ` Linus Torvalds
2023-12-30 20:59 ` Linus Torvalds
2023-12-31 11:56 ` David Laight
2023-12-31 11:41 ` David Laight
2023-12-29 20:58 ` [PATCH next 5/5] locking/osq_lock: Optimise vcpu_is_preempted() check David Laight
2023-12-30 3:13 ` Waiman Long
2023-12-30 15:57 ` Waiman Long
2023-12-30 22:37 ` David Laight
2023-12-29 22:11 ` [PATCH next 2/5] locking/osq_lock: Avoid dirtying the local cpu's 'node' in the osq_lock() fast path David Laight
2023-12-30 3:20 ` Waiman Long
2023-12-30 15:49 ` David Laight
2024-01-02 18:53 ` Boqun Feng
2024-01-02 23:32 ` David Laight
2023-12-30 19:40 ` [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code Linus Torvalds
2023-12-30 22:39 ` David Laight
2023-12-31 2:14 ` Waiman Long
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=ZY/6YCNJ7tSCmiGo@gmail.com \
--to=mingo@kernel.org \
--cc=David.Laight@aculab.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=will@kernel.org \
--cc=xinhui.pan@linux.vnet.ibm.com \
--cc=zengheng4@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.