On Mon, Sep 13, 2021 at 01:32:30PM +0200, Michal Hocko wrote: > The existing code (fs or other subsystem interacting with MM) is > going to require quite a lot of changes to move away from struct > page notion but I do not see folios to add fundamental blocker > there. The current folio seems to do quite a bit of that work, actually. But it'll be undone when the MM conversion matures the data structure into the full-blown new page. It's not about hopes and dreams, it's the simple fact that the patches do something now that seems very valuable, but which we'll lose again over time. And avoiding that is a relatively minor adjustment at this time compared to a much larger one later on. So yeah, it's not really a blocker. It's just a missed opportunity to lastingly disentangle struct page's multiple roles when touching all the relevant places anyway. It's also (needlessly) betting that compound pages can be made into a scalable, reliable, and predictable allocation model, and proliferating them into fs/ based on that. These patches, and all the ones that will need to follow to finish the conversion, are exceptionally expensive. It would have been nice to get more out of this disruption than to identify the relatively few places that genuinely need compound_head(), and having a datatype for N contiguous pages. Is there merit in solving those problems? Sure. Is it a robust, forward-looking direction for the MM space that justifies the cost of these and later patches? You seem to think so, I don't. It doesn't look like we'll agree on this. But I think I've made my points several times now, so I'll defer to Linus and Andrew.
