lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8ddec64-d87c-ae7a-9b02-2f24da2396e9@linux.alibaba.com>
Date:   Tue, 20 Aug 2019 11:00:39 +0800
From:   Joseph Qi <joseph.qi@...ux.alibaba.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Joseph Qi <jiangqi903@...il.com>,
        Dave Chinner <david@...morbit.com>,
        Andreas Dilger <adilger@...ger.ca>,
        Theodore Ts'o <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Xiaoguang Wang <xiaoguang.wang@...ux.alibaba.com>,
        Liu Bo <bo.liu@...ux.alibaba.com>
Subject: Re: [RFC] performance regression with "ext4: Allow parallel DIO
 reads"

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@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ