Re: [PATCH 6/7] mm: folio_may_be_cached() unless folio_test_large()

[David Hildenbrand]

On 08.09.25 22:04, Hugh Dickins wrote:
> On Mon, 8 Sep 2025, David Hildenbrand wrote:
> > On 08.09.25 13:19, Hugh Dickins wrote:
> ...
> > > (Settimg aside that I've never perceived those pagevecs/batches as a
> > > "cache"; but lru_cache_disable() gave us that terminology, and we've
> > > gone with the flow ever since.  lru_add_drain() would be better named
> > > lru_cache_drain() now, I've always got hung up on "adding a drain".)
> >
> > Yeah, the terminology is not that intuitive :)
> >
> > Not sure if using "batched" instead of "cached" might be clearer long-term?
> >
> > > "may be" rather than "maybe" was intentional: perhaps too subtle,
> > > but to a native speaker it neatly expresses both the "we can do this"
> > > and "might this have been done" cases.
> >
> > I would wish we could find something that also non-native speakers can
> > immediately understand ;)
> >
> > "may_get_lru_cached" / "may_get_lru_batched"?
> >
> > /me could not even phrase it in German properly
> >
> > > kernel-doc?  I don't think so, this is very much an mm-internal
> > > matter, and I don't care for the way kernel-doc forces us towards
> > > boilerplate ("@folio: The folio.") rather than helpful comment.
> >
> > So a comment that this is an internal helper might be nice. Or we just move it
> > straight to mm/internal.h ?
>
> mm/internal.h, where we hide things (GFP_RECLAIM_MASK etc!) that belong
> elsewhere?  No thanks.

Yes, or other mm-internal helpers that actually belong there. Like 
folio_raw_mapping() or folio_nr_pages_mapped().

> David, I think you're over-thinking this: I'm coming to regret not just
> going with your excellent folio_test_large() optimization, and let
> someone else mess around with the naming.

Please don't feel like I'm pushing to hard here. If you feel the current 
naming is fine and for some reason I don't completely understand it 
should not be in mm/internal.h, all good.

--
Cheers

David / dhildenb