Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp932333ybl; Fri, 16 Aug 2019 06:24:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzN/vBBXwk0Jd+JNaeX7W8WLlIoGBmMmlPuS3B5PuOKgcOPJZOb6hxa9sfG2A0cObsQrePj X-Received: by 2002:a65:5b8e:: with SMTP id i14mr7779934pgr.188.1565961866773; Fri, 16 Aug 2019 06:24:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565961866; cv=none; d=google.com; s=arc-20160816; b=YrHhIl4f2FXkZhGyxguuxtngj2lKjFot4Rr1hmulRnuGh4B4L0tfKLKTL+ugut9eYM wWJnL7v8Q+k/mEngLwp15P2ZDOl4DUmTw+EgTNMq8Mvy6ZQSBdh5YeCG6Xkie55odRve 2p2NnjITQarDiWRuF0hzmgcyoD6uxFEQRHvrOJMqWqq3PYsSbwvIh5LXwGF8Qi4CSVnR 41+EwROKkbgpeYDah2q5YW/fcROhSI6pBLTKmo0T0oBXpqblfHHCGI5GVxjfPXsfShgS yUtxN/YHPYTs/XFB4uWYwurxdhITtBIzMOSll1OPMFgH/tTmQQfkLjW8QURgyo/+QLnM ZaWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=wRgSPBr23BTxD3D8A0vwNNlJ5iKferNMVZDV1d+oeA8=; b=qRf6B4CAW9I9jkU3/D0pgu4frORRGv8olFOIgF1VHiqY99yV1sRgBB2Xx9CW6S+IhD tmSV75yzQq2rdjN7GMb3HIJLlunTvA6iSq8McL1SLD69gXyjgjjUMFJRJiHZmGzWKTPS YYvDUBmg9DgHGREa5UwTc+ub99mQzn63e6IMWv14K+IdoFaKCXWg7PelCJwYe63QOJKX G5j6e4Nm8c216qkKJgPJ4CDEFMLWbnCDhXtxLARny8oa2u6qYCBfVft3GyKZPO3jedhZ r6e2r4cqk2LM7u9KAAcbDzuvRgov/UUeoUwwfjsufo7G5To+wqd5LKn/Rx0+TcO603y5 oeHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 91si3915224plc.427.2019.08.16.06.24.00; Fri, 16 Aug 2019 06:24:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727312AbfHPNXk (ORCPT + 99 others); Fri, 16 Aug 2019 09:23:40 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:38217 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727240AbfHPNXh (ORCPT ); Fri, 16 Aug 2019 09:23:37 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0TZdbDa5_1565961805; Received: from JosephdeMacBook-Pro.local(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0TZdbDa5_1565961805) by smtp.aliyun-inc.com(127.0.0.1); Fri, 16 Aug 2019 21:23:25 +0800 Subject: Re: [RFC] performance regression with "ext4: Allow parallel DIO reads" To: Jan Kara , Joseph Qi Cc: Dave Chinner , Andreas Dilger , Theodore Ts'o , Ext4 Developers List , Xiaoguang Wang , Liu Bo References: <29d50d24-f8e7-5ef4-d4d8-3ea6fb1c6ed3@gmail.com> <6DADA28C-542F-45F6-ADB0-870A81ABED23@dilger.ca> <15112e38-94fe-39d6-a8e2-064ff47187d5@linux.alibaba.com> <20190728225122.GG7777@dread.disaster.area> <960bb915-20cc-26a0-7abc-bfca01aa39c0@gmail.com> <20190815151336.GO14313@quack2.suse.cz> From: Joseph Qi Message-ID: <075fd06f-b0b4-4122-81c6-e49200d5bd17@linux.alibaba.com> Date: Fri, 16 Aug 2019 21:23:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190815151336.GO14313@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Jan, Thanks for your reply. 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 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 have hard time remembering what I was thinking those couple years back > but I think the plan was to switch to dioread_nolock always but somehow I > didn't finish that and now I forgot where I got stuck because I don't see > any problem with that currently. Do you mean mark dioread_nolock as default? Thanks, Joseph > > Honza >