All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 2/4] fs: add support for LOOKUP_NONBLOCK
Date: Tue, 15 Dec 2020 11:44:31 -0700	[thread overview]
Message-ID: <01be1442-a4d1-6347-f955-3a28a8d253e7@kernel.dk> (raw)
In-Reply-To: <CAHk-=wgsdrdep8uT7DiWftUzW5E5tb_b6CRkMk0cb06q3yE_WQ@mail.gmail.com>

On 12/15/20 11:29 AM, Linus Torvalds wrote:
> On Tue, Dec 15, 2020 at 8:08 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> OK, ran some numbers. The test app benchmarks opening X files, I just
>> used /usr on my test box. That's 182677 files. To mimic real worldy
>> kind of setups, 33% of the files can be looked up hot, so LOOKUP_NONBLOCK
>> will succeed.
> 
> Perhaps more interestingly, what's the difference between the patchset
> as posted for just io_uring?
> 
> IOW, does the synchronous LOOKUP_NONBLOCK actually help?
> 
> I'm obviously a big believer in the whole "avoid thread setup costs if
> not necessary", so I'd _expect_ it to help, but maybe the possible
> extra parallelism is enough to overcome the thread setup and
> synchronization costs even for a fast cached RCU lookup.

For basically all cases on the io_uring side where I've ended up being
able to do the hot/fast path inline, it's been a nice win. The only real
exception to that rule is buffered reads that are fully cached, and
having multiple async workers copy the data is obviously always going to
be faster at some point due to the extra parallelism and memory
bandwidth. So yes, I too am a big believer in being able to perform
operations inline if at all possible, even if for some thing it turns
into a full retry when we fail. The hot path more than makes up for it.

> (I also suspect the reality is often much closer to 100% cached
> lookups than just 33%, but who knows - there are things like just
> concurrent renames that can cause the RCU lookup to fail even if it
> _was_ cached, so it's not purely about whether things are in the
> dcache or not).

In usecs again, same test, this time just using io_uring:

Cached		5.10-git	5.10-git+LOOKUP_NONBLOCK
--------------------------------------------------------
33%		1,014,975	900,474
100%		435,636		151,475

As expected, the closer we get to fully cached, the better off we are
with using LOOKUP_NONBLOCK. It's a nice win even at just 33% cached.

-- 
Jens Axboe


  reply	other threads:[~2020-12-15 18:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 19:13 [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Jens Axboe
2020-12-14 19:13 ` [PATCH 1/4] fs: make unlazy_walk() error handling consistent Jens Axboe
2020-12-14 19:13 ` [PATCH 2/4] fs: add support for LOOKUP_NONBLOCK Jens Axboe
2020-12-15 12:24   ` Matthew Wilcox
2020-12-15 15:29     ` Jens Axboe
2020-12-15 15:33       ` Matthew Wilcox
2020-12-15 15:37         ` Jens Axboe
2020-12-15 16:08           ` Jens Axboe
2020-12-15 16:14             ` Jens Axboe
2020-12-15 18:29             ` Linus Torvalds
2020-12-15 18:44               ` Jens Axboe [this message]
2020-12-15 18:47                 ` Linus Torvalds
2020-12-15 19:03                   ` Jens Axboe
2020-12-15 19:32                     ` Linus Torvalds
2020-12-15 19:38                       ` Jens Axboe
2020-12-16  2:36   ` Al Viro
2020-12-16  3:30     ` Jens Axboe
2020-12-16  2:43   ` Al Viro
2020-12-16  3:32     ` Jens Axboe
2020-12-14 19:13 ` [PATCH 3/4] fs: expose LOOKUP_NONBLOCK through openat2() RESOLVE_NONBLOCK Jens Axboe
2020-12-15 22:25   ` Dave Chinner
2020-12-15 22:31     ` Linus Torvalds
2020-12-15 23:25       ` Jens Axboe
2020-12-16  2:37   ` Al Viro
2020-12-16  3:39     ` Linus Torvalds
2020-12-14 19:13 ` [PATCH 4/4] io_uring: enable LOOKUP_NONBLOCK path resolution for filename lookups Jens Axboe
2020-12-15  3:06 ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Linus Torvalds
2020-12-15  3:18   ` Jens Axboe
2020-12-15  6:11 ` Al Viro
2020-12-15 15:29   ` Jens Axboe
2021-01-04  5:31 ` Al Viro
2021-01-04 14:43   ` Jens Axboe
2021-01-04 16:54     ` Al Viro
2021-01-04 17:03       ` Jens Axboe
     [not found] ` <m1lfbrwrgq.fsf@fess.ebiederm.org>
2021-02-14 16:38   ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?) Jens Axboe
2021-02-14 20:30     ` Linus Torvalds
2021-02-14 21:24       ` Al Viro
2021-02-15 18:07       ` Eric W. Biederman
2021-02-15 18:24         ` Jens Axboe
2021-02-15 21:09           ` Jens Axboe
2021-02-15 22:41             ` Eric W. Biederman
2021-02-16  2:41               ` Jens Axboe
2021-02-17  1:18                 ` Jens Axboe
2021-02-17  1:26                   ` Jens Axboe
2021-02-17  3:11                     ` Jens Axboe
2021-02-15 17:56     ` Eric W. Biederman

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=01be1442-a4d1-6347-f955-3a28a8d253e7@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.