Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3480368ybl; Mon, 19 Aug 2019 20:01:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7WbMjHSPJLtXoVpvnefRkts+eVQ7kWub4gpQfhVx+KPoClVwoMpIbH3vITkaRfOFqUHF3 X-Received: by 2002:a63:550d:: with SMTP id j13mr22948763pgb.173.1566270087577; Mon, 19 Aug 2019 20:01:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566270087; cv=none; d=google.com; s=arc-20160816; b=nQlgC5VtdSMquVwU2NF13OpA83qwcv28EDbUQCHRIam0bEDRU8PBZ+hGL8K+ma9EMP Kbn1uEnFoD3tE0EORqr89Yde6/OZTWqVQ2uQ44alx9DWThCelEyVcGczdCMH7CZg8Tx3 30nsXpq3hKdc52u/ZjwpAxjuAzfAMDXxGxDlcN3O1CRPd426LHEgIlMsHN6KIpuK8Ycw 89URfXxbzTS/7lVb+Nq3UUXF0g48ZOWNUGyeB2Y+md1qChPFSj4Qv+hj19HEkBtZNv1Q CvbIyuUDCa4ae3GOdp4J+pPStpEFw3aOSvOl+DA1kzji9ckoDmvlu0jKynCoiCrng4/k mP7A== 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=r7CUCXv9dRGcC1SQAR07aKucudRdc0Sd/1GnKieaA/I=; b=kC/4xaztQg9jXrBc6B1D9+02+/ds36D6oXspgWCXa2in87H2cQ55TzRgj/Uq6kIGx0 tKi4PojmyMiA2gqWTKl2QExE3uF8sqsooSpEsE1RvJu2n7GIPlKiN+EhoA+N8580CXwK lq5PXxlvDdyLCcoAlTDg3o70Tw4FAWT6OtAoh+zeWKaEAZ0WggDLZlrnpnNn2EkyxwS7 uCtfhasKQfXchHGQ05smjobUeKycP4cfRztC3zdEnrgKM542irniFp2Sr/g2TvguAG2y dgCbFqO3yY8MFutwMEEDgJs7DBUBLYxUM1peJanArJWyjjPQSbaFURklY7LmL1Kvrccn bODQ== 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 d9si11052899pgv.577.2019.08.19.20.01.00; Mon, 19 Aug 2019 20:01:27 -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 S1728734AbfHTDA6 (ORCPT + 99 others); Mon, 19 Aug 2019 23:00:58 -0400 Received: from out30-42.freemail.mail.aliyun.com ([115.124.30.42]:56720 "EHLO out30-42.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728719AbfHTDA6 (ORCPT ); Mon, 19 Aug 2019 23:00:58 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0TZy2p6q_1566270039; Received: from JosephdeMacBook-Pro.local(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0TZy2p6q_1566270039) by smtp.aliyun-inc.com(127.0.0.1); Tue, 20 Aug 2019 11:00:40 +0800 Subject: Re: [RFC] performance regression with "ext4: Allow parallel DIO reads" To: Jan Kara Cc: Joseph Qi , 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> <075fd06f-b0b4-4122-81c6-e49200d5bd17@linux.alibaba.com> <20190816145719.GA3041@quack2.suse.cz> From: Joseph Qi Message-ID: Date: Tue, 20 Aug 2019 11:00:39 +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: <20190816145719.GA3041@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, 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 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