Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp259321pxb; Wed, 20 Jan 2021 06:29:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4GvQJgVBLKE7dYtz/w5J97IzZ1dTVFRdIex1+EmB9NF22oxNj13/Rr5P7jFQotAZF55ry X-Received: by 2002:a17:906:6d44:: with SMTP id a4mr6746143ejt.453.1611152987816; Wed, 20 Jan 2021 06:29:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611152987; cv=none; d=google.com; s=arc-20160816; b=Zf97PTAlo5X0H2eWIH/yOEFVPt91IYNqs4LXbM8dxfaRFHjktOAjI9K0SrpWRK33qM hsaYIi2tRNFm7Qa4eB1oj/68IC9DtIRhhlZw6tgeVy6AGSii5vmXjVkBrMsIhpwLWEA3 jGPDz3ZwjBS+Hz4X208UFldqHlwaYittkNWHo7yosvlFNG0KS6/oNYUVz7JKn/sCIefY 7vRXydItS/KcrSKX6IgRIXP6B/k0NJCIHDJ2gC3lr5ShQ1dxY8MCPaNqsnLseIpRHBBj RhwftS0/XkHWiRng4P55ezg7B8OCOwlVjlZM3uOBALwvLDVaKL7bqPqqqlB02ayWP7wU vMWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=j0osvWW4qiN8qdHuZMQgFzuzjo107o7L0+DzXvAHrNs=; b=zCE9Yl0i7nhmmgW7nF11VMt6fRTGS7ocLasLuVPo7H/uDgYtXDuvPsljWMH1zOvLSt PYYb+acPvrrtd3phR26Ol8awCgMk1DONCw+HpZPjojp93zfi2nLRWUtEEZ5Z8JemehZl klZ9qH9B7H0CuTxq5/OPtrwuJtZFMA5aw8bf5EjtxanWto0wv+/vGfpBBXVAbW6fAMKj S1a2nZTABpkc5rG6TSTBjoQsjDfQveoWE8jQmtGR6OpPIm5eNaXIeeHBuTsRVx6b4oqO on90xhB0ILGiG+DXMXv4HoaoVnAsxCp9FLvlkZ8Rfbw/yseV8mF62TmGArDe/g7I5e2A Sb3g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p22si886957edt.391.2021.01.20.06.29.21; Wed, 20 Jan 2021 06:29:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388397AbhATO1U (ORCPT + 99 others); Wed, 20 Jan 2021 09:27:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:55878 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388178AbhATOTV (ORCPT ); Wed, 20 Jan 2021 09:19:21 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A2825AB7F; Wed, 20 Jan 2021 14:18:35 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 642A01E0802; Wed, 20 Jan 2021 15:18:34 +0100 (CET) Date: Wed, 20 Jan 2021 15:18:34 +0100 From: Jan Kara To: Dave Chinner Cc: Zhongwei Cai , Mikulas Patocka , Theodore Ts'o , Matthew Wilcox , David Laight , Mingkai Dong , Andrew Morton , Jan Kara , Steven Whitehouse , Eric Sandeen , Dave Chinner , Wang Jianchao , Rajesh Tadakamadla , linux-kernel , linux-fsdevel , linux-nvdimm Subject: Re: Expense of read_iter Message-ID: <20210120141834.GA24063@quack2.suse.cz> References: <20210107151125.GB5270@casper.infradead.org> <17045315-CC1F-4165-B8E3-BA55DD16D46B@gmail.com> <2041983017.5681521.1610459100858.JavaMail.zimbra@sjtu.edu.cn> <1224425872.715547.1610703643424.JavaMail.zimbra@sjtu.edu.cn> <20210120044700.GA4626@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210120044700.GA4626@dread.disaster.area> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 20-01-21 15:47:00, Dave Chinner wrote: > On Fri, Jan 15, 2021 at 05:40:43PM +0800, Zhongwei Cai wrote: > > On Thu, 14 Jan 2021, Mikulas wrote: > > For Ext4-dax, the overhead of dax_iomap_rw is significant > > compared to the overhead of struct iov_iter. Although methods > > proposed by Mikulas can eliminate the overhead of iov_iter > > well, they can not be applied in Ext4-dax unless we implement an > > internal "read" method in Ext4-dax. > > > > For Ext4-dax, there could be two approaches to optimizing: > > 1) implementing the internal "read" method without the complexity > > of iterators and dax_iomap_rw; > > Please do not go an re-invent the wheel just for ext4. If there's a > problem in a shared path - ext2, FUSE and XFS all use dax_iomap_rw() > as well, so any improvements to that path benefit all DAX users, not > just ext4. > > > 2) optimizing how dax_iomap_rw works. > > Since dax_iomap_rw requires ext4_iomap_begin, which further involves > > the iomap structure and others (e.g., journaling status locks in Ext4), > > we think implementing the internal "read" method would be easier. > > Maybe it is, but it's also very selfish. The DAX iomap path was > written to be correct for all users, not inecessarily provide > optimal performance. There will be lots of things that could be done > to optimise it, so rather than creating a special snowflake in ext4 > that makes DAX in ext4 much harder to maintain for non-ext4 DAX > developers, please work to improve the common DAX IO path and so > provide the same benefit to all the filesystems that use it. Yeah, I agree. I'm against ext4 private solution for this read problem. And I'm also against duplicating ->read_iter functionatily in ->read handler. The maintenance burden of this code duplication is IMHO just too big. We rather need to improve the generic code so that the fast path is faster. And every filesystem will benefit because this is not ext4 specific problem. Honza -- Jan Kara SUSE Labs, CR