From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DA7B029CA for ; Mon, 9 Aug 2021 22:34:56 +0000 (UTC) Received: from dread.disaster.area (pa49-195-182-146.pa.nsw.optusnet.com.au [49.195.182.146]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 919098552B; Tue, 10 Aug 2021 08:10:49 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1mDDTr-00GSfc-Td; Tue, 10 Aug 2021 08:10:47 +1000 Date: Tue, 10 Aug 2021 08:10:47 +1000 From: Dave Chinner To: Christoph Hellwig Cc: "Darrick J. Wong" , Dan Williams , Matthew Wilcox , Andreas Gruenbacher , Shiyang Ruan , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, nvdimm@lists.linux.dev, cluster-devel@redhat.com Subject: Re: [PATCH 11/30] iomap: add the new iomap_iter model Message-ID: <20210809221047.GC3657114@dread.disaster.area> References: <20210809061244.1196573-1-hch@lst.de> <20210809061244.1196573-12-hch@lst.de> Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210809061244.1196573-12-hch@lst.de> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=YKPhNiOx c=1 sm=1 tr=0 a=QpfB3wCSrn/dqEBSktpwZQ==:117 a=QpfB3wCSrn/dqEBSktpwZQ==:17 a=kj9zAlcOel0A:10 a=MhDmnRu9jo8A:10 a=JfrnYn6hAAAA:8 a=7-415B0cAAAA:8 a=c-sO9qzMkAf5MM67-4kA:9 a=CjuIK1q_8ugA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 On Mon, Aug 09, 2021 at 08:12:25AM +0200, Christoph Hellwig wrote: > The iomap_iter struct provides a convenient way to package up and > maintain all the arguments to the various mapping and operation > functions. It is operated on using the iomap_iter() function that > is called in loop until the whole range has been processed. Compared > to the existing iomap_apply() function this avoid an indirect call > for each iteration. > > For now iomap_iter() calls back into the existing ->iomap_begin and > ->iomap_end methods, but in the future this could be further optimized > to avoid indirect calls entirely. > > Based on an earlier patch from Matthew Wilcox . > > Signed-off-by: Christoph Hellwig > --- > fs/iomap/Makefile | 1 + > fs/iomap/core.c | 79 +++++++++++++++++++++++++++++++++++++++++++ > fs/iomap/trace.h | 37 +++++++++++++++++++- > include/linux/iomap.h | 56 ++++++++++++++++++++++++++++++ > 4 files changed, 172 insertions(+), 1 deletion(-) > create mode 100644 fs/iomap/core.c > > diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile > index eef2722d93a183..6b56b10ded347a 100644 > --- a/fs/iomap/Makefile > +++ b/fs/iomap/Makefile > @@ -10,6 +10,7 @@ obj-$(CONFIG_FS_IOMAP) += iomap.o > > iomap-y += trace.o \ > apply.o \ > + core.o \ This creates a discontinuity in the iomap git history. Can you add these new functions to iomap/apply.c, then when the old apply code is removed later in the series rename the file to core.c? At least that way 'git log --follow fs/iomap/core.c' will walk back into the current history of fs/iomap/apply.c and the older pre-disaggregation fs/iomap.c without having to take the tree back in time to find those files... Cheers, Dave. -- Dave Chinner david@fromorbit.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Date: Tue, 10 Aug 2021 08:10:47 +1000 Subject: [Cluster-devel] [PATCH 11/30] iomap: add the new iomap_iter model In-Reply-To: <20210809061244.1196573-12-hch@lst.de> References: <20210809061244.1196573-1-hch@lst.de> <20210809061244.1196573-12-hch@lst.de> Message-ID: <20210809221047.GC3657114@dread.disaster.area> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Aug 09, 2021 at 08:12:25AM +0200, Christoph Hellwig wrote: > The iomap_iter struct provides a convenient way to package up and > maintain all the arguments to the various mapping and operation > functions. It is operated on using the iomap_iter() function that > is called in loop until the whole range has been processed. Compared > to the existing iomap_apply() function this avoid an indirect call > for each iteration. > > For now iomap_iter() calls back into the existing ->iomap_begin and > ->iomap_end methods, but in the future this could be further optimized > to avoid indirect calls entirely. > > Based on an earlier patch from Matthew Wilcox . > > Signed-off-by: Christoph Hellwig > --- > fs/iomap/Makefile | 1 + > fs/iomap/core.c | 79 +++++++++++++++++++++++++++++++++++++++++++ > fs/iomap/trace.h | 37 +++++++++++++++++++- > include/linux/iomap.h | 56 ++++++++++++++++++++++++++++++ > 4 files changed, 172 insertions(+), 1 deletion(-) > create mode 100644 fs/iomap/core.c > > diff --git a/fs/iomap/Makefile b/fs/iomap/Makefile > index eef2722d93a183..6b56b10ded347a 100644 > --- a/fs/iomap/Makefile > +++ b/fs/iomap/Makefile > @@ -10,6 +10,7 @@ obj-$(CONFIG_FS_IOMAP) += iomap.o > > iomap-y += trace.o \ > apply.o \ > + core.o \ This creates a discontinuity in the iomap git history. Can you add these new functions to iomap/apply.c, then when the old apply code is removed later in the series rename the file to core.c? At least that way 'git log --follow fs/iomap/core.c' will walk back into the current history of fs/iomap/apply.c and the older pre-disaggregation fs/iomap.c without having to take the tree back in time to find those files... Cheers, Dave. -- Dave Chinner david at fromorbit.com