On Tue, Apr 06, 2021 at 01:48:07PM +0100, Matthew Wilcox wrote: > Now, maybe we should put this optimisation into the definition of nth_page? That would be nice. > > As Christoph, I'm not a fan of this :/ > > What would you prefer? Looking at your full folio series on git.infradead.org, there are a total of 12 references to non-page members of struct folio, assuming my crude grep that expects a folio to be named folio did not miss any. Except for one that prints folio->flags in cachefiles code, and which should go away they are all in core MM code in mm/ or include/. With enough file system conversions I do see potential uses for ->mapping and ->index outside of core code, but IMHO we can ignore those for now and just switch them over if/when we actually change the struct folio internals to split them from tail pages. So my opinion is: leave these fields out for now, and when the problem that we'd have a lot of reference out of core code arises deal with it once we know about the scope. Maybe we add wrappers for the few members that are reasonable "public", maybe we then do the union trick you have here because it is the least evil, or maybe we just do not do anything at all until these fields move over to the folio entirely.
