From: Rik van Riel <riel@surriel.com>
To: linux-kernel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Gladkov <legion@kernel.org>,
linux-fs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH RFC] fs,ipc: batch RCU synchronization in free_ipc
Date: Mon, 15 Aug 2022 17:26:20 -0400 [thread overview]
Message-ID: <20220815172620.5d7d4a78@imladris.surriel.com> (raw)
TL;DR: it runs better than it looks, and I am looking for ideas on how to make it look better
---8<---
The following program will get ENOSPACE sooner or later, because
the way ipc namespaces get freed currently results in only one
ipc namespace being freed every RCU grace period.
int main()
{
int i;
for (i = 0; i < 1000000; i++) {
if (unshare(CLONE_NEWIPC) < 0)
error(EXIT_FAILURE, errno, "unshare");
}
}
There are various ways to solve this issue, they all come down to
batching the RCU synchronization, so multiple ipc namespaces can
be freed in the same RCU grace period.
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.
Signed-off-by: Rik van Riel <riel@surriel.com>
---
ipc/namespace.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/ipc/namespace.c b/ipc/namespace.c
index e1fcaedba4fa..ba33015f1a23 100644
--- a/ipc/namespace.c
+++ b/ipc/namespace.c
@@ -127,10 +127,6 @@ void free_ipcs(struct ipc_namespace *ns, struct ipc_ids *ids,
static void free_ipc_ns(struct ipc_namespace *ns)
{
- /* mq_put_mnt() waits for a grace period as kern_unmount()
- * uses synchronize_rcu().
- */
- mq_put_mnt(ns);
sem_exit_ns(ns);
msg_exit_ns(ns);
shm_exit_ns(ns);
@@ -144,14 +140,33 @@ static void free_ipc_ns(struct ipc_namespace *ns)
kfree(ns);
}
+#define FREE_IPC_BATCH 64
static LLIST_HEAD(free_ipc_list);
static void free_ipc(struct work_struct *unused)
{
- struct llist_node *node = llist_del_all(&free_ipc_list);
- struct ipc_namespace *n, *t;
+ struct ipc_namespace *ipc_nses[FREE_IPC_BATCH];
+ struct vfsmount *mounts[FREE_IPC_BATCH];
+ int i, j;
+
+ next_batch:
+ i = 0;
+ for (i = 0; !llist_empty(&free_ipc_list) && i < FREE_IPC_BATCH; i++) {
+ struct llist_node *node = llist_del_first(&free_ipc_list);
+ struct ipc_namespace *n = llist_entry(node,
+ struct ipc_namespace,
+ mnt_llist);
+ ipc_nses[i] = n;
+ mounts[i] = n->mq_mnt;
+ }
+
+ /* Consolidate the RCU synchronization across the whole batch. */
+ kern_unmount_array(mounts, i);
+
+ for (j = 0; j < i; j++)
+ free_ipc_ns(ipc_nses[j]);
- llist_for_each_entry_safe(n, t, node, mnt_llist)
- free_ipc_ns(n);
+ if (i == FREE_IPC_BATCH)
+ goto next_batch;
}
/*
--
2.24.1
next reply other threads:[~2022-08-16 5:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 21:26 Rik van Riel [this message]
2022-08-15 21:40 ` Al Viro
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=20220815172620.5d7d4a78@imladris.surriel.com \
--to=riel@surriel.com \
--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=viro@zeniv.linux.org.uk \
/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®