Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7217298ybp; Wed, 16 Oct 2019 05:38:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqw+MmXN8e5BQepomdMn3b+f72gMdXeE4Ixl7cUV3IWn1ODzFNYptET/6s7Ugatz0CedI6wq X-Received: by 2002:a05:6402:1252:: with SMTP id l18mr38912992edw.64.1571229529074; Wed, 16 Oct 2019 05:38:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571229529; cv=none; d=google.com; s=arc-20160816; b=f1C2BnsWiOEX4yamUpeGScATMGVjP8nNZDzQv2Ao4ELcxvOJcEtrVnmmlDMaPCNXVh NddzO7Za2pwzpGf3QZHlpRLwPelIHJ774vYOui3sXtyr9gCly8m2bWn2O7BAnRMSWAky mtr4Cgf6+Un+n/iN6MtJ3JdjAlwCU3cAjrcgakel+ZXVXfIWS9h/a5d68m8+fl0dpnnw d29NzoBthE0Chlhn74zf6Qa9wsMZvFrf2UfsuljOU59P0z/QngTnhrqvlTEuXetYf2er 4C/iOCwJOeXmegmx/QmfOyQ3O5WuJ61RaW5UeaWZqN4lu5MJ4hDg4GHKQepq7561oXFC B/eA== 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=dY9Xp75VKtCFPOp2oGJvzPDGMu6bm7kicAe/0RCdJ0A=; b=sI1yLwgrptWXwmjbsgs0AuFxfJ4Y00c1yYkRmPGQJ9OHXzSwj6FEjhQmyuVMR2l1VD F7tfRFYWmYq76e36mO+YzltWVAwzsaOVDlI44cwfcNYfoAO5kvc8kwnLnrRjC7VWsREm /rXDltPZWsydxGzBqnAT1VWfbn+IJ/Lcx2eWD0SL+jVruNhYp2r32DqW9By57bRX6KHJ AYUQXNLNNE/Mvi0+ultwfqTK3lXlDqlfhHgBOgBmAH8nx+ohgQRiN6JFU0/Ev53ybnCj aaH/XXiGmUtLsQmZvpM0FP3bfF9bjzJM3M5paeE66yN532+co3LBa2TJRVJcHzRp2Gq6 QhAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 c9si19048253eda.229.2019.10.16.05.38.26; Wed, 16 Oct 2019 05:38:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391296AbfJPHsm (ORCPT + 99 others); Wed, 16 Oct 2019 03:48:42 -0400 Received: from verein.lst.de ([213.95.11.211]:59511 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726872AbfJPHsl (ORCPT ); Wed, 16 Oct 2019 03:48:41 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 3189868B20; Wed, 16 Oct 2019 09:48:37 +0200 (CEST) Date: Wed, 16 Oct 2019 09:48:36 +0200 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , "Darrick J . Wong" , Damien Le Moal , Andreas Gruenbacher , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/12] iomap: lift the xfs writeback code to iomap Message-ID: <20191016074836.GB23696@lst.de> References: <20191015154345.13052-1-hch@lst.de> <20191015154345.13052-10-hch@lst.de> <20191015220721.GC16973@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191015220721.GC16973@dread.disaster.area> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 16, 2019 at 09:07:21AM +1100, Dave Chinner wrote: > > + trace_iomap_releasepage(page->mapping->host, page, 0, 0); > > + > > /* > > * mm accommodates an old ext3 case where clean pages might not have had > > * the dirty bit cleared. Thus, it can send actual dirty pages to > > @@ -483,6 +488,8 @@ EXPORT_SYMBOL_GPL(iomap_releasepage); > > void > > iomap_invalidatepage(struct page *page, unsigned int offset, unsigned int len) > > { > > + trace_iomap_invalidatepage(page->mapping->host, page, offset, len); > > + > > These tracepoints should be split out into a separate patch like > the readpage(s) tracepoints. Maybe just lift all the non-writeback > ones in a single patch... I guess that makes sense. Initially I didn't want to duplicate the trace definition as it is shared with the writeback tracepoints, but in the overall scheme of things that doesn't really matter. > > +iomap_finish_page_writeback(struct inode *inode, struct bio_vec *bvec, > > + int error) > > +{ > > + struct iomap_page *iop = to_iomap_page(bvec->bv_page); > > + > > + if (error) { > > + SetPageError(bvec->bv_page); > > + mapping_set_error(inode->i_mapping, -EIO); > > + } > > + > > + WARN_ON_ONCE(i_blocksize(inode) < PAGE_SIZE && !iop); > > + WARN_ON_ONCE(iop && atomic_read(&iop->write_count) <= 0); > > + > > + if (!iop || atomic_dec_and_test(&iop->write_count)) > > + end_page_writeback(bvec->bv_page); > > +} > > Can we just pass the struct page into this function? I'd rather not change calling conventions in code just moved over for no good reason. That being said I agree with passing a page, so I'll just throw in a follow on patch like I did for iomap_ioend_compare cleanup. > > ..... > > > +/* > > + * Submit the bio for an ioend. We are passed an ioend with a bio attached to > > + * it, and we submit that bio. The ioend may be used for multiple bio > > + * submissions, so we only want to allocate an append transaction for the ioend > > + * once. In the case of multiple bio submission, each bio will take an IO > > This needs to be changed to describe what wpc->ops->submit_ioend() > is used for rather than what XFS might use this hook for. True. The real documentation now is in the header near the ops defintion, but I'll update this one to make more sense as well. > > +static int > > +iomap_submit_ioend(struct iomap_writepage_ctx *wpc, struct iomap_ioend *ioend, > > + int error) > > +{ > > + ioend->io_bio->bi_private = ioend; > > + ioend->io_bio->bi_end_io = iomap_writepage_end_bio; > > + > > + if (wpc->ops->submit_ioend) > > + error = wpc->ops->submit_ioend(ioend, error); > > I'm not sure that "submit_ioend" is the best name for this method, > as it is a pre-bio-submission hook, not an actual IO submission > method. "prepare_ioend_for_submit" is more descriptive, but probably > too long. wpc->ops->prepare_submit(ioend, error) reads pretty well, > though... Not a huge fan of that name either, but Brian complained. Let's hold a popular vote for a name and see if we have a winner. As for the grammar comments - all this is copied over as-is. I'll add another patch to fix that up.