From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-block <linux-block@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 3/3] io_uring: add io_uring_event cache hit information
Date: Sat, 16 Mar 2019 10:27:15 -0600 [thread overview]
Message-ID: <b294af4d-7df6-b5f3-cf93-3aa958b9ec8b@kernel.dk> (raw)
In-Reply-To: <CAHk-=wg3iyLvh4L2us0WZc18UPKwFtZYA2L5h3OnP01a+T+59w@mail.gmail.com>
On 3/15/19 7:34 PM, Linus Torvalds wrote:
> On Fri, Mar 15, 2019 at 9:27 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Linus, curious on your opinion on this one. I had this as part of the
>> original series, but removed it from the pull request due to the
>> mincore etc discussions.
>
> I'd rather not have new ways to leak cache information, and in fact
> already the IOCB_NOWAIT is a bit questionable for that. But afaik, the
> non-O_DIRECT paths don't even support it to begin with for some
> filesystems.
For the most popular it works fine, though. For buffered async IO it'd
be nice to have it be fully reliable, so we can ensure we punt when we
have to. Currently for writes, we just ignore it and punt to async,
since it doesn't work at all there. The latter should be fixable.
On the hint, I hear ya, that's what I figured. I'll drop the patch for
now.
> Wasn't the whole point of this io_ring that we'd move *away* from
> direct block access and O_DIRECT?
>
> I'm seeing a lot of stuff that looks like just "more of the same old
> O_DIRECT garbage" that seems to be all about thinking that IO doesn't
> cache.
>
> Haven't we gotten over that already? It was one of the arguments you
> used for io_ring to begin with.
There are still folks that use it, even if O_DIRECT is nasty. If you
want to get peak performance, there's no way around it. That doesn't
mean that io_uring is in any way centered around O_DIRECT at all, it
isn't. At its core, it's "just" an efficient delivery mechanism for
submissions and completions.
Not sure what "stuff" you are referring to, the patches in this short
series? That's not centered around block devices at all, works just fine
for files. The bvec iterator is what io_uring uses for fixed buffers,
it's not exclusive to block devices at all.
--
Jens Axboe
prev parent reply other threads:[~2019-03-16 16:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 14:59 [PATCHSET 0/3] io_uring improvements Jens Axboe
2019-03-15 14:59 ` [PATCH 1/3] iov_iter: add ITER_BVEC_FLAG_NO_REF flag Jens Axboe
2019-03-15 14:59 ` [PATCH 2/3] block: add BIO_NO_PAGE_REF flag Jens Axboe
2019-03-15 14:59 ` [PATCH 3/3] io_uring: add io_uring_event cache hit information Jens Axboe
2019-03-15 16:27 ` Jens Axboe
2019-03-16 1:34 ` Linus Torvalds
2019-03-16 16:27 ` Jens Axboe [this message]
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=b294af4d-7df6-b5f3-cf93-3aa958b9ec8b@kernel.dk \
--to=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=torvalds@linux-foundation.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).