From: Al Viro <viro@zeniv.linux.org.uk>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Gladkov <legion@kernel.org>,
linux-fs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH RFC] fs,ipc: batch RCU synchronization in free_ipc
Date: Mon, 15 Aug 2022 22:40:26 +0100 [thread overview]
Message-ID: <Yvq9SmCUX/eeUuR1@ZenIV> (raw)
In-Reply-To: <20220815172620.5d7d4a78@imladris.surriel.com>
On Mon, Aug 15, 2022 at 05:26:20PM -0400, Rik van Riel wrote:
> TL;DR: it runs better than it looks, and I am looking for ideas on how to make it look better
> Unfortunately there seems to be a tradeoff between temporarily
> allocating things on the stack, and having slightly uglier code,
> or adding a struct rcu_work to the struct vfsmount.
>
> I am not entirely happy with the way this code looks, and hoping
> for suggestions on how to improve it.
>
> However, I am quite happy with how this code runs. Between batching
> the kern_unmount RCU synchronization, moving to the expedited RCU
> grace period in kern_unmount_array, and grabbing things off the
> llist that were added after the work item started, freeing ipc
> namespaces is 2-3 orders of magnitude faster than before, and
> able to keep up with the test case above.
IMO you are going in wrong direction with that; it's a long story,
and I've partial writeup on that, but I won't have it ready for
posting until the end of the week. Put it that way - there's
a possibility of reorganizing the way mount refcounts work,
eliminating this synchronize_rcu(). RCU delay still has to happen
in some form, but we get smarter ways to wait for it.
Anyway, it's about 15 pages of writeup right now, and it's going
to be a major massage, part for the coming cycle, part for the
next one. I'll post it to fsdevel later this week, will make sure
to Cc you.
next prev parent reply other threads:[~2022-08-16 5:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 21:26 [PATCH RFC] fs,ipc: batch RCU synchronization in free_ipc Rik van Riel
2022-08-15 21:40 ` Al Viro [this message]
2022-08-16 1:05 ` Rik van Riel
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=Yvq9SmCUX/eeUuR1@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=ebiederm@xmission.com \
--cc=kernel-team@fb.com \
--cc=legion@kernel.org \
--cc=linux-fs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox