linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Cc: 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 13:50:21 +0200	[thread overview]
Message-ID: <20200705115021.GA1227929@kroah.com> (raw)
In-Reply-To: <CAODFU0q6CrUB_LkSdrbp5TQ4Jm6Sw=ZepZwD-B7-aFudsOvsig@mail.gmail.com>

On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> Hello
> 
> 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.

> Without the ability to read multiple small files using a single system
> call, it is impossible to increase IOPS (unless an application is
> using multiple reader threads or somehow instructs the kernel to
> prefetch multiple files into memory).

There's not much (but it is mesurable) need to prefetch virtual files
into memory first, which is primarily what this syscall is for (procfs,
sysfs, securityfs, etc.)  If you are dealing with real-disks, then yes,
the overhead of the syscall might be in the noise compared to the i/o
path of the data.

> While you are at it, why not also add a readfiles system call to read
> multiple, presumably small, files? The initial unoptimized
> implementation of readfiles syscall can simply call readfile
> sequentially.

Again, that's what io_uring is for.

thanks,

greg k-h

  parent reply	other threads:[~2020-07-05 11:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05  2:06 [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster 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 [this message]
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=20200705115021.GA1227929@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=0xe2.0x9a.0x9b@gmail.com \
    --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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).