linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: mtk.manpages@gmail.com, shuah@kernel.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-man@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Date: Sun, 5 Jul 2020 13:47:06 +0200	[thread overview]
Message-ID: <20200705114706.GA1227487@kroah.com> (raw)
In-Reply-To: <20200704193040.GC2786714@ZenIV.linux.org.uk>

On Sat, Jul 04, 2020 at 08:30:40PM +0100, Al Viro wrote:
> On Sat, Jul 04, 2020 at 04:02:46PM +0200, Greg Kroah-Hartman wrote:
> > Here is a tiny new syscall, readfile, that makes it simpler to read
> > small/medium sized files all in one shot, no need to do open/read/close.
> > This is especially helpful for tools that poke around in procfs or
> > sysfs, making a little bit of a less system load than before, especially
> > as syscall overheads go up over time due to various CPU bugs being
> > addressed.
> 
> Nice series, but you are 3 months late with it...  Next AFD, perhaps?

Perhaps :)

> Seriously, the rationale is bollocks.  If the overhead of 2 extra
> syscalls is anywhere near the costs of the real work being done by
> that thing, we have already lost and the best thing to do is to
> throw the system away and start with saner hardware.

The real-work the kernel does is almost neglegant compared to the
open/close overhead of the syscalls on some platforms today.  I'll post
benchmarks with the next version of this patch series to hopefully show
that.  If not, then yeah, this isn't worth it, but it was fun to write.

thanks,

greg k-h

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

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-04 14:02 [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster Greg Kroah-Hartman
2020-07-04 14:02 ` [PATCH 1/3] readfile: implement readfile syscall Greg Kroah-Hartman
2020-07-04 18:35   ` Geert Uytterhoeven
2020-07-04 19:14   ` Matthew Wilcox
2020-07-04 19:41   ` Miklos Szeredi
2020-07-04 20:12     ` Al Viro
2020-07-04 20:16       ` Al Viro
2020-07-04 14:02 ` [PATCH 2/3] arch: wire up the " Greg Kroah-Hartman
2020-07-04 18:36   ` Geert Uytterhoeven
2020-07-04 14:02 ` [PATCH 3/3] selftests: add readfile(2) selftests Greg Kroah-Hartman
2020-07-04 18:38   ` Geert Uytterhoeven
2020-07-05  6:55     ` Greg Kroah-Hartman
2020-07-05 11:24       ` Geert Uytterhoeven
2020-07-05 11:36         ` Greg Kroah-Hartman
2020-07-05  1:41   ` Heinrich Schuchardt
2020-07-05  7:34     ` Greg Kroah-Hartman
2020-07-05  9:46       ` Heinrich Schuchardt
2020-07-04 14:02 ` [PATCH] readfile.2: new page describing readfile(2) Greg Kroah-Hartman
2020-07-05  2:54   ` Heinrich Schuchardt
2020-07-04 19:30 ` [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster Al Viro
2020-07-05 11:47   ` Greg Kroah-Hartman [this message]
2020-07-06 17:25 ` Dave Martin
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
2020-07-15  9:00                 ` Pavel Begunkov
2020-07-15 11:17                   ` Miklos Szeredi

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=20200705114706.GA1227487@kroah.com \
    --to=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 \
    /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).