Re: [RFCv2 1/3] iomap: Move creation of iomap_page early in __iomap_write_begin

[Christoph Hellwig <hch@infradead.org>]

On Mon, Jan 30, 2023 at 09:44:11PM +0530, Ritesh Harjani (IBM) wrote:
> The problem is that commit[1] moved iop creation later i.e. after checking for
> whether the folio is uptodate. And if the folio is uptodate, it simply
> returns and doesn't allocate a iop.
> Now what can happen is that during __iomap_write_begin() for bs < ps,
> there can be a folio which is marked uptodate but does not have a iomap_page
> structure allocated.
> (I think one of the reason it can happen is due to memory pressure, we
> can end up freeing folio->private resource).
> 
> Thus the iop structure will only gets allocated at the time of writeback
> in iomap_writepage_map(). This I think, was a not problem till now since
> we anyway only track uptodate status in iop (no support of tracking
> dirty bitmap status which later patches will add), and we also end up
> setting all the bits in iomap_page_create(), if the page is uptodate.

delayed iop allocation is a feature and not a bug.  We might have to
refine the criteria for sub-page dirty tracking, but in general having
the iop allocates is a memory and performance overhead and should be
avoided as much as possible.  In fact I still have some unfinished
work to allocate it even more lazily.