public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] pipe: nonblocking rw for io_uring
Date: Mon, 24 Apr 2023 15:55:48 -0600	[thread overview]
Message-ID: <ae8ee8f3-9960-1fd9-5471-433acacb6521@kernel.dk> (raw)
In-Reply-To: <CAHk-=wiQ8g+B0bCPJ9fxZ+Oa0LPAUAyryw9i+-fBUe72LoA+QQ@mail.gmail.com>

On 4/24/23 3:37?PM, Linus Torvalds wrote:
> On Mon, Apr 24, 2023 at 2:22?PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> If we don't ever wait for IO with the pipe lock held, then we can skip
>> the conditional locking. But with splice, that's not at all the case! We
>> most certainly wait for IO there with the pipe lock held.
> 
> I think that then needs to just be fixed.

I took another look at this, and the main issue is in fact splice
confirming buffers. So I do think that we can make this work by simply
having the non-block nature of it being passed down the ->confirm()
callback as that's the one that'll be waiting for IO. If we have that,
then we can disregard the pipe locking as we won't be holding it over
IO.

Which is what part of this series does, notably patch 1.

Only other oddity is pipe_to_sendpage(), which we can probably sanely
ignore.

IOW, would you be fine with a v2 of this pull request where patch 2
drops the conditional locking and just passes it to ->confirm()? That's
certainly sane, and just makes the ultimate page locking conditional to
avoid waiting on IO. I'd really hate to still be missing out on pipe
performance with io_uring.

-- 
Jens Axboe


  reply	other threads:[~2023-04-24 21:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21 14:01 [GIT PULL] pipe: nonblocking rw for io_uring Christian Brauner
2023-04-24 21:05 ` Linus Torvalds
2023-04-24 21:22   ` Jens Axboe
2023-04-24 21:37     ` Linus Torvalds
2023-04-24 21:55       ` Jens Axboe [this message]
2023-04-24 22:00         ` Linus Torvalds
2023-04-24 22:05           ` Jens Axboe
2023-04-24 22:03         ` Jens Axboe
2023-04-24 21:58       ` Linus Torvalds
2023-04-24 22:07         ` Jens Axboe
2023-04-24 22:44           ` Jens Axboe
2023-04-25  3:16             ` Linus Torvalds
2023-04-25 13:46               ` Jens Axboe
2023-04-25 17:20               ` Linus Torvalds
2023-04-25 19:49                 ` Peter Zijlstra
2023-04-25 19:58                   ` Linus Torvalds
2023-04-25 20:10                     ` Jens Axboe
2023-04-25 20:29                     ` Linus Torvalds
     [not found]                     ` <978690c4-1d25-46e8-3375-45940ec1ea51@huaweicloud.com>
2023-05-08  8:39                       ` Peter Zijlstra
2023-05-08 10:16                         ` David Laight

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=ae8ee8f3-9960-1fd9-5471-433acacb6521@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox