Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: gregkh@linuxfoundation.org, linux-api@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-man@vger.kernel.org,
	mtk.manpages@gmail.com, shuah@kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Date: Sun, 5 Jul 2020 06:09:03 +0200	[thread overview]
Message-ID: <CAODFU0rSqQsO9rSiA8Ke=+mk_NgEdFDHPMfmXGSmzmkqQh1KYw@mail.gmail.com> (raw)
In-Reply-To: <20200705032732.GT25523@casper.infradead.org>

On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > You should probably take a look at io_uring.  That has the level of
> > > complexity of this proposal and supports open/read/close along with many
> > > other opcodes.
> >
> > Then glibc can implement readfile using io_uring and there is no need
> > for a new single-file readfile syscall.
>
> It could, sure.  But there's also a value in having a simple interface
> to accomplish a simple task.  Your proposed API added a very complex
> interface to satisfy needs that clearly aren't part of the problem space
> that Greg is looking to address.

I believe that we should look at the single-file readfile syscall from
a performance viewpoint. If an application is expecting to read a
couple of small/medium-size files per second, then neither readfile
nor readfiles makes sense in terms of improving performance. The
benefits start to show up only in case an application is expecting to
read at least a hundred of files per second. The "per second" part is
important, it cannot be left out. Because readfile only improves
performance for many-file reads, the syscall that applications
performing many-file reads actually want is the multi-file version,
not the single-file version.

I am not sure I understand why you think that a pointer to an array of
readfile_t structures is very complex. If it was very complex then it
would be a deep tree or a large graph.

  reply	other threads:[~2020-07-05  4:09 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 [this message]
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
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

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='CAODFU0rSqQsO9rSiA8Ke=+mk_NgEdFDHPMfmXGSmzmkqQh1KYw@mail.gmail.com' \
    --to=0xe2.0x9a.0x9b@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=shuah@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --subject='Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster' \
    /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

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).