io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>,
	io-uring <io-uring@vger.kernel.org>
Subject: Re: [RFC] do_hashed and wq enqueue
Date: Tue, 11 Feb 2020 13:30:09 -0700	[thread overview]
Message-ID: <00a3935a-043a-ee60-2206-2e62ec8c2936@kernel.dk> (raw)
In-Reply-To: <f0662f54-3964-9cef-151d-3102c9280757@gmail.com>

On 2/11/20 1:20 PM, Pavel Begunkov wrote:
> Hi,
> 
> I've been looking for hashed io-wq enqueuing, but not fully understand the
> issue. As I remember, it was something about getting around blocking for
> buffered I/O. Is that so? Is there any write-up of a thread for this issue?

Not sure if there's a writeup, but the issue is that buffered writes all
need to grab the per-inode mutex. Hence if you don't serialize these writes,
you end up having potentially quite a few threads banging on the same mutex.
This causes a high level of lock contention (and scheduling). By serializing
by inode hash we avoid that, and yield the same performance.

Dave Chinner is working on lifting this restriction, at which point we'll
have to gate the hashing based on whether or not the fs is smart or dumb
when it comes to buffered writes and locking.

> My case is 2-fd request, and I'm not sure how it should look. For splice() it's
> probably Ok to hash the non-pipe end (if any), but I wonder how it should work,
> if, for example, the restriction will be removed.

Probably just do the same, but for the output fd only (and following the
same restrictions in terms of file type).

-- 
Jens Axboe


  reply	other threads:[~2020-02-11 20:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 20:20 [RFC] do_hashed and wq enqueue Pavel Begunkov
2020-02-11 20:30 ` Jens Axboe [this message]
2020-02-11 20:36   ` Pavel Begunkov

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=00a3935a-043a-ee60-2206-2e62ec8c2936@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=io-uring@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).