On Tue, Jul 14, 2020 at 1:36 PM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote: > > On 14/07/2020 11:07, Miklos Szeredi wrote: > > On Tue, Jul 14, 2020 at 8:51 AM Pavel Machek <pavel@xxxxxxx> wrote: > >> > >> Hi! > >> > >>>> 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. Thanks, Miklos
