Re: [PATCH RFC] mm: fix refcount check in mapping_evict_folio

[Boris Burkov <boris@bur.io>]

On Wed, Aug 14, 2024 at 04:15:25AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 13, 2024 at 12:58:09PM -0700, Shakeel Butt wrote:
> > > +	/*
> > > +	 * The refcount will be elevated if any page in the folio is mapped.
> > > +	 *
> > > +	 * The refcounts break down as follows:
> > > +	 * 1 per mapped page
> > > +	 * 1 from folio_attach_private, if private is set
> > > +	 * 1 from allocating the page in the first place
> > > +	 * 1 from the caller
> > > +	 */
> > 
> > I think the above explanation is correct at least from my code
> > inspection. Most of the callers are related to memory failure. I would
> > reword the "1 per mapped page" to "1 per page in page cache" or
> > something as mapped here might mean mapped in page tables.
> 
> It's not though.  The "1 from allocating the page in the first place"
> is donated to the page cache.  It's late here and I don't have the
> ability to work through what's really going on here.

Can you explain what you mean by "donated to the page cache" more
precisely?

Perhaps there is something better btrfs can do with its refcounting
as it calls alloc_pages_bulk_array, then filemap_add_folio, and finally
folio_attach_private. But I am not sure which of those refcounts we can
(or should?) drop.

Thanks,
Boris