Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4253278ybl; Tue, 20 Aug 2019 09:08:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzuX7Qin/lzzUwxGUP3NkwQtucq2kTUEUr+vWTkYBh/xFMQAjOyiM8HgYVA87dNn/Xj43+D X-Received: by 2002:a17:90b:911:: with SMTP id bo17mr740187pjb.40.1566317330559; Tue, 20 Aug 2019 09:08:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566317330; cv=none; d=google.com; s=arc-20160816; b=Xdf7t/iTp06UBIEs1gxoRIT+w6i3NbFepIw761e9lixU6S8crMsOT1R3NhtjWFVtq6 +AtBSovzl/INDQVdDu9uxJmox1udJJzcWupEOGnBh96XkFJgLpbDAkI5P03luO7rLSW6 8uw8VD7h/OuL/8VaPHgn5L0Jmp4skUQ6mF7MOI9hU3ZtfEkXmRiskWWql07DODlQDK8S lyArU2LBYpv3MbrQy0pBi2+G7uDqskUgmx+Vo3ypaWuarO//0sAtj8lY2YAnnP/EC+gF mX4nzWxraGLMMUVsxzXI4Cc6W6f32xFeV5uIRNQZbPMpZqEKF2MqfcybyJ8aCBSSKXvw YGlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=qQYaV2wLc5u11iX/dlner1uW1UcEsfq25mBWIeuMdLY=; b=gaM5mfMM8RVi68YBTYylzb4nEQBxp8lMH6WqTnRz8jhaD8r3wQTvPFF/uH8wUmDciw bhJUP+dWmelerfyPaUzzi+EIh2xxUYIn+sVXWKGGFpRXFYgOVK7orDav5Eh/8v5GL9RM wPrKHXEg5OvBnPYDWEBQOqlEJo8DzERm++GN33GVG+CQPXn106+s4pR0GNVy1QW0LPml fWpGY5JtvvVU5NhJT0EhDuNzw3RnvIbKoJYU7O/qYo15laUoIvThyR10PtfZiTxOkE5I QjkUfTD+ipmvkOZiCEvE4u9N6G7tn+b3WewvDFQFL1dzu75NB0ApPZuy1TxqcGBuwiod Rl1A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w4si242478pjr.76.2019.08.20.09.08.24; Tue, 20 Aug 2019 09:08:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729819AbfHTQIW (ORCPT + 99 others); Tue, 20 Aug 2019 12:08:22 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:46213 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728283AbfHTQIW (ORCPT ); Tue, 20 Aug 2019 12:08:22 -0400 Received: from callcc.thunk.org (wsip-184-188-36-2.sd.sd.cox.net [184.188.36.2]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7KG86c1019512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 12:08:08 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 9A3BB420843; Tue, 20 Aug 2019 12:08:05 -0400 (EDT) Date: Tue, 20 Aug 2019 12:08:05 -0400 From: "Theodore Y. Ts'o" To: Joseph Qi Cc: Jan Kara , Joseph Qi , Dave Chinner , Andreas Dilger , Ext4 Developers List , Xiaoguang Wang , Liu Bo Subject: Re: [RFC] performance regression with "ext4: Allow parallel DIO reads" Message-ID: <20190820160805.GB10232@mit.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Aug 20, 2019 at 11:00:39AM +0800, Joseph Qi wrote: > > 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(). Why is that a problem? It's a shared lock, so parallel threads should be able to issue reads without getting serialized? Are you using sufficiently fast storage devices that you're worried about cache line bouncing of the shared lock? Or do you have some other concern, such as some other thread taking an exclusive lock? - Ted