[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegvv-SPJRjWrR_+JY-H=xmYq0pnTfAtj-N8kG7AnQvWd=w@mail.gmail.com>
Date: Tue, 18 Apr 2023 14:42:03 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Jens Axboe <axboe@...nel.dk>
Cc: "Darrick J. Wong" <djwong@...nel.org>,
Christoph Hellwig <hch@...radead.org>,
Bernd Schubert <bschubert@....com>, io-uring@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-xfs@...r.kernel.org, dsingh@....com
Subject: Re: [PATCH 1/2] fs: add FMODE_DIO_PARALLEL_WRITE flag
On Sat, 15 Apr 2023 at 15:15, Jens Axboe <axboe@...nel.dk> wrote:
> Yep, that is pretty much it. If all writes to that inode are serialized
> by a lock on the fs side, then we'll get a lot of contention on that
> mutex. And since, originally, nothing supported async writes, everything
> would get punted to the io-wq workers. io_uring added per-inode hashing
> for this, so that any punt to io-wq of a write would get serialized.
>
> IOW, it's an efficiency thing, not a correctness thing.
We could still get a performance regression if the majority of writes
still trigger the exclusive locking. The questions are:
- how often does that happen in real life?
- how bad the performance regression would be?
Without first attempting to answer those questions, I'd be reluctant
to add FMODE_DIO_PARALLEL_WRITE to fuse.
Thanks,
Miklos
Powered by blists - more mailing lists