From: Ingo Molnar <mingo@kernel.org>
To: David Laight <David.Laight@aculab.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
"'peterz@infradead.org'" <peterz@infradead.org>,
"'longman@redhat.com'" <longman@redhat.com>,
"'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>,
"'virtualization@lists.linux-foundation.org'"
<virtualization@lists.linux-foundation.org>,
'Zeng Heng' <zengheng4@huawei.com>
Subject: Re: [PATCH next v2 2/5] locking/osq_lock: Optimise the vcpu_is_preempted() check.
Date: Tue, 2 Jan 2024 10:49:32 +0100 [thread overview]
Message-ID: <ZZPcLJSbfab8pweu@gmail.com> (raw)
In-Reply-To: <3a9d1782cd50436c99ced8c10175bae6@AcuMS.aculab.com>
* David Laight <David.Laight@ACULAB.COM> wrote:
> The vcpu_is_preempted() test stops osq_lock() spinning if a virtual
> cpu is no longer running.
>
> Although patched out for bare-metal the code still needs the cpu number.
Comma missing.
> Reading this from 'prev->cpu' is a pretty much guaranteed have a cache miss
> when osq_unlock() is waking up the next cpu.
>
> Instead save 'prev->cpu' in 'node->prev_cpu' and use that value instead.
> Update in the osq_lock() 'unqueue' path when 'node->prev' is changed.
>
> This is simpler than checking for 'node->prev' changing and caching
> 'prev->cpu'.
Throughout the series, in changelogs and comments, please do:
s/cpu
/CPU
Please be more careful about changelog quality.
> struct optimistic_spin_node {
> struct optimistic_spin_node *next, *prev;
> - int locked; /* 1 if lock acquired */
> - int cpu; /* encoded CPU # + 1 value */
> + int locked; /* 1 if lock acquired */
> + int cpu; /* encoded CPU # + 1 value */
> + int prev_cpu; /* encoded CPU # + 1 value */
> };
s/ encoded CPU # + 1 value
/ encoded value: CPU+1
Thanks,
Ingo
next prev parent reply other threads:[~2024-01-02 9:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 21:49 [PATCH next v2 0/5] locking/osq_lock: Optimisations to osq_lock code David Laight
2023-12-31 21:51 ` [PATCH next v2 1/5] locking/osq_lock: Defer clearing node->locked until the slow osq_lock() path David Laight
2024-01-01 4:08 ` Waiman Long
2024-01-02 9:49 ` Ingo Molnar
2024-01-02 9:51 ` Ingo Molnar
2023-12-31 21:52 ` [PATCH next v2 2/5] locking/osq_lock: Optimise the vcpu_is_preempted() check David Laight
2024-01-01 4:09 ` Waiman Long
2024-01-02 9:49 ` Ingo Molnar [this message]
2024-01-08 7:42 ` kernel test robot
2023-12-31 21:54 ` [PATCH next v2 3/5] locking/osq_lock: Use node->prev_cpu instead of saving node->prev David Laight
2024-01-01 4:09 ` Waiman Long
2023-12-31 21:54 ` [PATCH next v2 4/5] locking/osq_lock: Avoid writing to node->next in the osq_lock() fast path David Laight
2024-01-01 4:13 ` Waiman Long
2024-01-02 9:47 ` Ingo Molnar
2023-12-31 21:55 ` [PATCH next v2 5/5] locking/osq_lock: Optimise decode_cpu() and per_cpu_ptr() David Laight
2024-01-01 4:14 ` Waiman Long
2024-01-01 8:47 ` David Laight
2024-05-03 15:59 ` Waiman Long
2024-05-03 16:16 ` David Laight
2024-05-03 21:10 ` David Laight
2024-05-03 22:13 ` Waiman Long
2024-05-04 20:26 ` David Laight
2024-01-02 9:54 ` Ingo Molnar
2024-01-02 10:20 ` David Laight
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=ZZPcLJSbfab8pweu@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=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.