Thread (27 messages) flat view 27 messages, 8 authors, 2020-07-15

Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster

From: Pavel Begunkov <asml.silence@gmail.com>
Date: 2020-07-15 09:02:12
Also in: io-uring, linux-fsdevel, linux-kselftest, linux-man, lkml

On 15/07/2020 11:49, Pavel Begunkov wrote:
On 15/07/2020 11:41, Miklos Szeredi wrote:
quoted
On Wed, Jul 15, 2020 at 10:33 AM Pavel Begunkov [off-list ref] wrote:
quoted
On 14/07/2020 14:55, Miklos Szeredi wrote:
quoted
On Tue, Jul 14, 2020 at 1:36 PM Pavel Begunkov [off-list ref] wrote:
quoted
On 14/07/2020 11:07, Miklos Szeredi wrote:
quoted
On Tue, Jul 14, 2020 at 8:51 AM Pavel Machek [off-list ref] wrote:
quoted
Hi!
quoted
quoted
At first, I thought that the proposed system call is capable of
reading *multiple* small files using a single system call - which
would help increase HDD/SSD queue utilization and increase IOPS (I/O
operations per second) - but that isn't the case and the proposed
system call can read just a single file.
If you want to do this for multple files, use io_ring, that's what it
was designed for.  I think Jens was going to be adding support for the
open/read/close pattern to it as well, after some other more pressing
features/fixes were finished.
What about... just using io_uring for single file, too? I'm pretty
sure it can be wrapped in a library that is simple to use, avoiding
need for new syscall.
Just wondering:  is there a plan to add strace support to io_uring?
And I don't just mean the syscalls associated with io_uring, but
tracing the ring itself.
What kind of support do you mean? io_uring is asynchronous in nature
with all intrinsic tracing/debugging/etc. problems of such APIs.
And there are a lot of handy trace points, are those not enough?

Though, this can be an interesting project to rethink how async
APIs are worked with.
Yeah, it's an interesting problem.  The uring has the same events, as
far as I understand, that are recorded in a multithreaded strace
output (syscall entry, syscall exit); nothing more is needed>
I do think this needs to be integrated into strace(1), otherwise the
usefulness of that tool (which I think is *very* high) would go down
drastically as io_uring usage goes up.
Not touching the topic of usefulness of strace + io_uring, but I'd rather
have a tool that solves a problem, than a problem that created and honed
for a tool.
Sorry, I'm not getting the metaphor.  Can you please elaborate?
Sure, I mean _if_ there are tools that conceptually suit better, I'd
prefer to work with them, then trying to shove a new and possibly alien
infrastructure into strace.

But my knowledge of strace is very limited, so can't tell whether that's
the case. E.g. can it utilise static trace points?
I think, if you're going to push this idea, we should start a new thread
CC'ing strace devs.
	
-- 
Pavel Begunkov
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help