public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
	Joseph Qi <joseph.qi@linux.alibaba.com>,
	Theodore Ts'o <tytso@mit.edu>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/3] Revert parallel dio reads
Date: Fri, 30 Aug 2019 17:35:20 +0200	[thread overview]
Message-ID: <20190830153520.GB25069@quack2.suse.cz> (raw)
In-Reply-To: <8C1DC2C7-4389-446D-8233-EEDAAD38C398@dilger.ca>

On Thu 29-08-19 13:06:22, Andreas Dilger wrote:
> On Aug 29, 2019, at 4:58 AM, Jan Kara <jack@suse.cz> wrote:
> > 
> > On Tue 27-08-19 21:51:18, Dave Chinner wrote:
> >> On Tue, Aug 27, 2019 at 10:05:49AM +0800, Joseph Qi wrote:
> >>> This patch set is trying to revert parallel dio reads feature at present
> >>> since it causes significant performance regression in mixed random
> >>> read/write scenario.
> >>> 
> >>> Joseph Qi (3):
> >>>  Revert "ext4: remove EXT4_STATE_DIOREAD_LOCK flag"
> >>>  Revert "ext4: fix off-by-one error when writing back pages before dio
> >>>    read"
> >>>  Revert "ext4: Allow parallel DIO reads"
> >>> 
> >>> fs/ext4/ext4.h        | 17 +++++++++++++++++
> >>> fs/ext4/extents.c     | 19 ++++++++++++++-----
> >>> fs/ext4/inode.c       | 47 +++++++++++++++++++++++++++++++----------------
> >>> fs/ext4/ioctl.c       |  4 ++++
> >>> fs/ext4/move_extent.c |  4 ++++
> >>> fs/ext4/super.c       | 12 +++++++-----
> >>> 6 files changed, 77 insertions(+), 26 deletions(-)
> >> 
> >> Before doing this, you might want to have a chat and co-ordinate
> >> with the folks that are currently trying to port the ext4 direct IO
> >> code to use the iomap infrastructure:
> >> 
> >> https://lore.kernel.org/linux-ext4/20190827095221.GA1568@poseidon.bobrowski.net/T/#t
> >> 
> >> That is going to need the shared locking on read and will work just
> >> fine with shared locking on write, too (it's the code that XFS uses
> >> for direct IO). So it might be best here if you work towards shared
> >> locking on the write side rather than just revert the shared locking
> >> on the read side....
> > 
> > Yeah, after converting ext4 DIO path to iomap infrastructure, using shared
> > inode lock for all aligned non-extending DIO writes will be easy so I'd
> > prefer if we didn't have to redo the iomap conversion patches due to these
> > reverts.
> 
> But if the next kernel is LTS and the iomap implementation isn't in the
> current merge window (very unlikely) then we're stuck with this performance
> hit for LTS.  It is also unlikely that LTS will take the revert patches if
> they have not been landed to master.

I agree this is not great but the regression is there for 3 years, it has
been released in major distribution kernels quite a long time ago, and only
now someone complained. So it doesn't seem many people care about
performance of mixed RW workload when mounted with dioread_nolock (note
that the patches actually improve performance of read-only DIO workload
when not using dioread_nolock as for that case, exclusive lock is replaced
with a shared one).

									Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2019-08-30 15:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27  2:05 [PATCH 0/3] Revert parallel dio reads Joseph Qi
2019-08-27  2:05 ` [PATCH 1/3] Revert "ext4: remove EXT4_STATE_DIOREAD_LOCK flag" Joseph Qi
2019-08-27  2:05 ` [PATCH 2/3] Revert "ext4: fix off-by-one error when writing back pages before dio read" Joseph Qi
2019-08-27  2:05 ` [PATCH 3/3] Revert "ext4: Allow parallel DIO reads" Joseph Qi
2019-08-27 11:51 ` [PATCH 0/3] Revert parallel dio reads Dave Chinner
2019-08-29 10:58   ` Jan Kara
2019-08-29 19:06     ` Andreas Dilger
2019-08-30 15:35       ` Jan Kara [this message]
2019-09-10 14:10     ` Ritesh Harjani
2019-09-10 21:57       ` Jan Kara
2019-09-11 14:20         ` Ritesh Harjani

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=20190830153520.GB25069@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger@dilger.ca \
    --cc=david@fromorbit.com \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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