[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98802.1597220949@warthog.procyon.org.uk>
Date: Wed, 12 Aug 2020 09:29:09 +0100
From: David Howells <dhowells@...hat.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: dhowells@...hat.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>, Karel Zak <kzak@...hat.com>,
Jeff Layton <jlayton@...hat.com>,
Miklos Szeredi <mszeredi@...hat.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Christian Brauner <christian@...uner.io>,
Lennart Poettering <lennart@...ttering.net>,
Linux API <linux-api@...r.kernel.org>,
Ian Kent <raven@...maw.net>,
LSM <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information)
Miklos Szeredi <miklos@...redi.hu> wrote:
> Worried about performance? Io-uring will allow you to do all those
> five syscalls (or many more) with just one I/O submission.
io_uring isn't going to help here. We're talking about synchronous reads.
AIUI, you're adding a couple more syscalls to the list and running stuff in a
side thread to save the effort of going in and out of the kernel five times.
But you still have to pay the set up/tear down costs on the fds and do the
pathwalks. io_uring doesn't magically make that cost disappear.
io_uring also requires resources such as a kernel accessible ring buffer to
make it work.
You're proposing making everything else more messy just to avoid a dedicated
syscall. Could you please set out your reasoning for that?
David
Powered by blists - more mailing lists