On Aug 29, 2019, at 4:58 AM, Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx/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. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
