Thread (62 messages) 62 messages, 5 authors, 2021-07-30

Re: [PATCH v15 16/17] iomap: Convert iomap_add_to_ioend to take a folio

From: "Darrick J. Wong" <djwong@kernel.org>
Date: 2021-07-21 15:28:40
Also in: linux-fsdevel, linux-mm

On Wed, Jul 21, 2021 at 05:31:16AM +0100, Matthew Wilcox wrote:
On Wed, Jul 21, 2021 at 05:27:49AM +0100, Christoph Hellwig wrote:
quoted
On Tue, Jul 20, 2021 at 05:12:19PM -0700, Darrick J. Wong wrote:
quoted
I /am/ beginning to wonder, though -- seeing as Christoph and Matthew
both have very large patchsets changing things in fs/iomap/, how would
you like those landed?  Christoph's iterator refactoring looks like it
could be ready to go for 5.15.  Matthew's folio series looks like a
mostly straightforward conversion for iomap, except that it has 91
patches as a hard dependency.

Since most of the iomap changes for 5.15 aren't directly related to
folios, I think I prefer iomap-for-next to be based directly off -rcX
like usual, though I don't know where that leaves the iomap folio
conversion.  I suppose one could add them to a branch that itself is a
result of the folio and iomap branches, or leave them off for 5.16?
Maybe willy has a different opinion, but I thought the plan was to have
the based folio enablement in 5.15, and then do things like the iomap
conversion in the the next merge window.  If we have everything ready
this window we could still add a branch that builds on top of both
the iomap and folio trees, though.
Yes, my plan was to have the iomap conversion and the second half of the
page cache work hit 5.16.  If we're ready earlier, that's great!  Both
you and I want to see both the folio work and the iomap_iter work
get merged, so I don't anticipate any lack of will to get the work done.
Ok, good.  I'll await a non-RFC version of the iterator rework for 5.15,
and folio conversions for 5.16.

--D
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help