From: Waiman Long <llong@redhat.com>
To: Cruz Zhao <CruzZhao@linux.alibaba.com>,
peterz@infradead.org, mingo@redhat.com, boqun.feng@gmail.com,
will@kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] percpu_rwsem: let percpu_rwsem writer get rwsem faster
Date: Thu, 27 Mar 2025 23:58:51 -0400 [thread overview]
Message-ID: <8ee10a0a-b257-4141-b955-0097b43405e6@redhat.com> (raw)
In-Reply-To: <20250328030519.897032-1-CruzZhao@linux.alibaba.com>
On 3/27/25 11:05 PM, Cruz Zhao wrote:
> In the scenario where a large number of containers are created
> at the same time, there will be a lot of tasks created in a
> short time, and they will be written into cgroup.procs.
>
> copy_process() will require the cgroup_threadgroup_rwsem read
> lock, cgroup_procs_write will require the cgroup_threadgroup_rwsem
> write lock. As the readers will pre-increase the read_count and
> then check whether there is any writers, resulting that the
> writer may be starving, especially when there is a steady stream
> of readers.
>
> To alleviate this problem, we add one more check whether there
> are writers waiting before increasing the read_count, to make
> writers getting lock faster.
>
> Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com>
> ---
> kernel/locking/percpu-rwsem.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/locking/percpu-rwsem.c b/kernel/locking/percpu-rwsem.c
> index 6083883c4fe0..66bf18c28b43 100644
> --- a/kernel/locking/percpu-rwsem.c
> +++ b/kernel/locking/percpu-rwsem.c
> @@ -47,6 +47,11 @@ EXPORT_SYMBOL_GPL(percpu_free_rwsem);
>
> static bool __percpu_down_read_trylock(struct percpu_rw_semaphore *sem)
> {
> + if (unlikely(atomic_read_acquire(&sem->block))) {
> + rcuwait_wake_up(&sem->writer);
> + return false;
> + }
> +
> this_cpu_inc(*sem->read_count);
>
> /*
The specific sequence of events are there for a reason. If we disturb
the sequence like that, there is a possibility that a percpu_up_write()
may miss a waiting reader, for example. So a more careful analysis has
to be done.
BTW, how much performance benefit did you gain by making this change? We
certainly need to see some performance metrics.
The design of percpu rwsem prefers readers more with much less
performance overhead than regular rwsem. It also assumes writers come in
once in a while. To be more fair to writer, we use rwsem.
Cheers,
Longman
prev parent reply other threads:[~2025-03-28 3:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 3:05 Cruz Zhao
2025-03-28 3:58 ` Waiman Long [this message]
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=8ee10a0a-b257-4141-b955-0097b43405e6@redhat.com \
--to=llong@redhat.com \
--cc=CruzZhao@linux.alibaba.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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®