linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "Darrick J . Wong" <darrick.wong@oracle.com>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/11] iomap: copy the xfs writeback code to iomap.c
Date: Tue, 8 Oct 2019 18:37:08 +1100	[thread overview]
Message-ID: <20191008073708.GG16973@dread.disaster.area> (raw)
In-Reply-To: <20191008063436.GA30465@lst.de>

On Tue, Oct 08, 2019 at 08:34:36AM +0200, Christoph Hellwig wrote:
> On Tue, Oct 08, 2019 at 08:43:53AM +1100, Dave Chinner wrote:
> > > +static int
> > > +iomap_ioend_compare(void *priv, struct list_head *a, struct list_head *b)
> > > +{
> > > +	struct iomap_ioend *ia, *ib;
> > > +
> > > +	ia = container_of(a, struct iomap_ioend, io_list);
> > > +	ib = container_of(b, struct iomap_ioend, io_list);
> > > +	if (ia->io_offset < ib->io_offset)
> > > +		return -1;
> > > +	else if (ia->io_offset > ib->io_offset)
> > > +		return 1;
> > > +	return 0;
> > 
> > No need for the else here.
> 
> That is usually my comment :)  But in this case it is just copied over
> code, so I didn't want to do cosmetic changes.

*nod*

> > > +	/*
> > > +	 * Given that we do not allow direct reclaim to call us, we should
> > > +	 * never be called while in a filesystem transaction.
> > > +	 */
> > > +	if (WARN_ON_ONCE(current->flags & PF_MEMALLOC_NOFS))
> > > +		goto redirty;
> > 
> > Is this true for all expected callers of these functions rather than
> > just XFS? i.e. PF_MEMALLOC_NOFS is used by transactions in XFS to
> > prevent transaction context recursion, but other filesystems do not
> > do this..
> > 
> > FWIW, I can also see that this is going to cause us problems if high
> > level code starts using memalloc_nofs_save() and then calling
> > filemap_datawrite() and friends...
> 
> We have the check for direct reclaim just above, so any file system
> using this iomap code will not allow direct reclaim.  Which I think is
> a very good idea given that direct reclaim through the file system is
> a very bad idea.

*nod*

> That leaves with only the filemap_datawrite case, which so far is
> theoretical.  If that ever becomes a think it is very obvious and we
> can just remove the debug check.

I expect it will be a thing sooner rather than later...

> > > +iomap_writepage(struct page *page, struct writeback_control *wbc,
> > > +		struct iomap_writepage_ctx *wpc,
> > > +		const struct iomap_writeback_ops *ops)
> > > +{
> > > +	int ret;
> > > +
> > > +	wpc->ops = ops;
> > > +	ret = iomap_do_writepage(page, wbc, wpc);
> > > +	if (!wpc->ioend)
> > > +		return ret;
> > > +	return iomap_submit_ioend(wpc, wpc->ioend, ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(iomap_writepage);
> > 
> > Can we kill ->writepage for iomap users, please? After all, we don't
> > mostly don't allow memory reclaim to do writeback of dirty pages,
> > and that's the only caller of ->writepage.
> 
> I'd rather not do this as part of this move.  But if you could expedite
> your patch to kill ->writepage from the large block size support patch
> and submit it ASAP on top of this series I would be very much in favor.

Ok, looks like the usual of more follow up patches on top of these.
I'm kinda waiting for these to land before porting the large block
size stuff on top of it...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2019-10-08  7:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-06 15:45 lift the xfs writepage code into iomap v6 Christoph Hellwig
2019-10-06 15:45 ` [PATCH 01/11] iomap: add tracing for the readpage / readpages Christoph Hellwig
2019-10-06 22:43   ` Darrick J. Wong
2019-10-07  5:48     ` Christoph Hellwig
2019-10-07  6:17       ` Christoph Hellwig
2019-10-07 15:23         ` Darrick J. Wong
2019-10-07 13:00   ` Brian Foster
2019-10-06 15:45 ` [PATCH 02/11] iomap: copy the xfs writeback code to iomap.c Christoph Hellwig
2019-10-07 21:43   ` Dave Chinner
2019-10-08  6:34     ` Christoph Hellwig
2019-10-08  7:37       ` Dave Chinner [this message]
2019-10-06 15:46 ` [PATCH 03/11] iomap: warn on inline maps in iomap_writepage_map Christoph Hellwig
2019-10-06 15:46 ` [PATCH 04/11] xfs: set IOMAP_F_NEW more carefully Christoph Hellwig
2019-10-06 15:46 ` [PATCH 05/11] iomap: zero newly allocated mapped blocks Christoph Hellwig
2019-10-07 21:46   ` Dave Chinner
2019-10-07 22:08     ` Dave Chinner
2019-10-06 15:46 ` [PATCH 06/11] xfs: remove the readpage / readpages tracing code Christoph Hellwig
2019-10-06 15:46 ` [PATCH 07/11] xfs: initialize iomap->flags in xfs_bmbt_to_iomap Christoph Hellwig
2019-10-06 15:46 ` [PATCH 08/11] xfs: use a struct iomap in xfs_writepage_ctx Christoph Hellwig
2019-10-07 21:54   ` Dave Chinner
2019-10-08  6:42     ` Christoph Hellwig
2019-10-06 15:46 ` [PATCH 09/11] xfs: remove the fork fields in the writepage_ctx and ioend Christoph Hellwig
2019-10-07 21:59   ` Dave Chinner
2019-10-08  6:12     ` Christoph Hellwig
2019-10-06 15:46 ` [PATCH 10/11] xfs: use the iomap writeback code Christoph Hellwig
2019-10-07 13:06   ` Brian Foster
2019-10-07 15:25   ` Darrick J. Wong
2019-10-06 15:46 ` [PATCH 11/11] iomap: move struct iomap_page out of iomap.h Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2019-10-01  7:11 lift the xfs writepage code into iomap v5 Christoph Hellwig
2019-10-01  7:11 ` [PATCH 02/11] iomap: copy the xfs writeback code to iomap.c Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008073708.GG16973@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=agruenba@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).