Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jan Ziak <0xe2.0x9a.0x9b@gmail.com>
Cc: Greg KH <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: Mon, 6 Jul 2020 12:11:11 +0100	[thread overview]
Message-ID: <20200706111111.GX25523@casper.infradead.org> (raw)
In-Reply-To: <CAODFU0ovM-i=4fNKSzp9SgO_FjPcAOZ0R8S4iRXyGm+QL53C1A@mail.gmail.com>

On Mon, Jul 06, 2020 at 08:07:46AM +0200, Jan Ziak wrote:
> On Sun, Jul 5, 2020 at 1:58 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > It also is a measurable increase over reading just a single file.
> > Here's my really really fast AMD system doing just one call to readfile
> > vs. one call sequence to open/read/close:
> >
> >         $ ./readfile_speed -l 1
> >         Running readfile test on file /sys/devices/system/cpu/vulnerabilities/meltdown for 1 loops...
> >         Took 3410 ns
> >         Running open/read/close test on file /sys/devices/system/cpu/vulnerabilities/meltdown for 1 loops...
> >         Took 3780 ns
> >
> > 370ns isn't all that much, yes, but it is 370ns that could have been
> > used for something else :)
> 
> I am curious as to how you amortized or accounted for the fact that
> readfile() first needs to open the dirfd and then close it later.
> 
> >From performance viewpoint, only codes where readfile() is called
> multiple times from within a loop make sense:
> 
> dirfd = open();
> for(...) {
>   readfile(dirfd, ...);
> }
> close(dirfd);

dirfd can be AT_FDCWD or if the path is absolute, dirfd will be ignored,
so one does not have to open anything.  It would be an optimisation
if one wanted to read several files relating to the same process:

char dir[50];
sprintf(dir, "/proc/%d", pid);
dirfd = open(dir);
readfile(dirfd, "maps", ...);
readfile(dirfd, "stack", ...);
readfile(dirfd, "comm", ...);
readfile(dirfd, "environ", ...);
close(dirfd);

but one would not have to do that.


  reply	other threads:[~2020-07-06 11:11 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 [this message]
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=20200706111111.GX25523@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=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 \
    --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).