Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pavel Begunkov <email@example.com>
To: Miklos Szeredi <firstname.lastname@example.org>
Cc: Pavel Machek <email@example.com>,
Greg KH <firstname.lastname@example.org>,
Jan Ziak <email@example.com>,
Linux API <firstname.lastname@example.org>,
Michael Kerrisk <email@example.com>,
firstname.lastname@example.org, Al Viro <email@example.com>,
Subject: Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Date: Wed, 15 Jul 2020 11:49:36 +0300 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 15/07/2020 11:41, Miklos Szeredi wrote:
> On Wed, Jul 15, 2020 at 10:33 AM Pavel Begunkov <email@example.com> wrote:
>> On 14/07/2020 14:55, Miklos Szeredi wrote:
>>> On Tue, Jul 14, 2020 at 1:36 PM Pavel Begunkov <firstname.lastname@example.org> wrote:
>>>> On 14/07/2020 11:07, Miklos Szeredi wrote:
>>>>> On Tue, Jul 14, 2020 at 8:51 AM Pavel Machek <email@example.com> wrote:
>>>>>>>> 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?
next prev parent reply other threads:[~2020-07-15 8:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-05 2:06 Jan Ziak
2020-07-05 2:16 ` Matthew Wilcox
2020-07-05 2:46 ` Jan Ziak
2020-07-05 3:12 ` Matthew Wilcox
2020-07-05 3:18 ` Jan Ziak
2020-07-05 3:27 ` Matthew Wilcox
2020-07-05 4:09 ` Jan Ziak
2020-07-05 11:58 ` Greg KH
2020-07-06 6:07 ` Jan Ziak
2020-07-06 11:11 ` Matthew Wilcox
2020-07-06 11:18 ` Greg KH
2020-07-05 8:07 ` Vito Caputo
2020-07-05 11:44 ` Greg KH
2020-07-05 20:34 ` Vito Caputo
2020-07-05 6:32 ` Andreas Dilger
2020-07-05 7:25 ` Jan Ziak
2020-07-05 12:00 ` Greg KH
2020-07-05 11:50 ` Greg KH
2020-07-14 6:51 ` Pavel Machek
2020-07-14 8:07 ` Miklos Szeredi
2020-07-14 11:34 ` Pavel Begunkov
2020-07-14 11:55 ` Miklos Szeredi
2020-07-15 8:31 ` Pavel Begunkov
2020-07-15 8:41 ` Miklos Szeredi
2020-07-15 8:49 ` Pavel Begunkov [this message]
2020-07-15 9:00 ` Pavel Begunkov
2020-07-15 11:17 ` Miklos Szeredi
-- strict thread matches above, loose matches on Subject: below --
2020-07-04 14:02 Greg Kroah-Hartman
2020-07-04 19:30 ` Al Viro
2020-07-05 11:47 ` Greg Kroah-Hartman
2020-07-06 17:25 ` Dave Martin
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).