Re: [RFC] performance regression with "ext4: Allow parallel DIO reads"

[Joseph Qi <joseph.qi@linux.alibaba.com>]

Hi Jan,

On 19/8/16 22:57, Jan Kara wrote:
> On Fri 16-08-19 21:23:24, Joseph Qi wrote:
>> On 19/8/15 23:13, Jan Kara wrote:
>>> On Tue 30-07-19 09:34:39, Joseph Qi wrote:
>>>> On 19/7/29 06:51, Dave Chinner wrote:
>>>>> On Fri, Jul 26, 2019 at 09:12:07AM +0800, Joseph Qi wrote:
>>>>>>
>>>>>>
>>>>>> On 19/7/26 05:20, Andreas Dilger wrote:
>>>>>>>
>>>>>>>> On Jul 23, 2019, at 5:17 AM, Joseph Qi <jiangqi903@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi Ted & Jan,
>>>>>>>> Could you please give your valuable comments?
>>>>>>>
>>>>>>> It seems like the original patches should be reverted?  There is no data
>>>>>>
>>>>>> From my test result, yes.
>>>>>> I've also tested libaio with iodepth 16, it behaves the same. Here is the test
>>>>>> data for libaio 4k randrw:
>>>>>>
>>>>>> -------------------------------------------------------------------------------------------
>>>>>> w/ parallel dio reads | READ 78313KB/s, 19578, 1698.70us  | WRITE 78313KB/s, 19578, 4837.60us
>>>>>> -------------------------------------------------------------------------------------------
>>>>>> w/o parallel dio reads| READ 387774KB/s, 96943, 1009.73us | WRITE 387656KB/s，96914, 308.87us
>>>>>> -------------------------------------------------------------------------------------------
>>>>>>
>>>>>> Since this commit went into upstream long time ago，to be precise, Linux
>>>>>> 4.9, I wonder if someone else has also observed this regression, or
>>>>>> anything I missed?
>>>>>
>>>>> I suspect that the second part of this set of mods that Jan had
>>>>> planned to do (on the write side to use shared locking as well)
>>>>> did not happen and so the DIO writes are serialising the workload.
>>>>>
>>>>
>>>> Thanks for the inputs, Dave.
>>>> Hi Jan, Could you please confirm this?
>>>> If so, should we revert this commit at present?
>>>
>>> Sorry for getting to you only now. I was on vacation and then catching up
>>> with various stuff. I suppose you are not using dioread_nolock mount
>>> option, are you? Can you check what are your results with that mount
>>> option?
>>>
>> Yes, I've just used default mount options when testing. And it is indeed
>> that there is performance improvement with dioread_nolock after reverting
>> the 3 related commits.
>> I'll do a supplementary test with parallel dio reads as well as
>> dioread_nolock and send out the test result.

I've tested parallel dio reads with dioread_nolock, it doesn't have
significant performance improvement and still poor compared with reverting
parallel dio reads. IMO, this is because with parallel dio reads, it take
inode shared lock at the very beginning in ext4_direct_IO_read().

Thanks,
Joseph