Snipped, reordered: On Fri, Sep 17, 2021 at 12:31:36PM -0400, Johannes Weiner wrote: > 2. Are compound pages a scalable, future-proof allocation strategy? > > For 2), nobody knows the answer to this. Nobody. Anybody who claims to > do so is full of sh*t. Maybe compound pages work out, maybe they > don't. We can talk a million years about larger page sizes, how to > handle internal fragmentation, the difficulties of implementing a > chunk cache, but it's completely irrelevant because it's speculative. Calling it compound pages here is a misnomer, and it confuses the discussion. The question is really about whether we should start using higher order allocations for data in the page cache, and perhaps a better way of framing that question is: should we continue to fragment all our page cache allocations up front into individual pages? But I don't think this really the blocker. > 1. Is the folio a good descriptor for all uses of anon and file pages > inside MM code way beyond the page cache layer YOU care about? > > For some people the answers are yes, for others they are a no. The anon page conversion does seem to be where all the disagreement is coming from. So my ask, to everyone involved is - if anonymous pages are dropped from the folio patches, do we have any other real objections to the patch series? It's an open question as to how much anonymous pages are like file pages, and if we continue down the route of of splitting up struct page into separate types whether anonymous pages should be the same time as file pages. Also, it appears even file pages aren't fully converted to folios in Willy's patch set - grepping around reveals plenty of references to struct page left in fs/. I think that even if anonymous pages are going to become folios it's a pretty reasonable ask for that to wait a cycle or two and see how the conversion of file pages fully plays out. Also: it's become pretty clear to me that we have crappy communications between MM developers and filesystem developers. Internally both teams have solid communications - I know in filesystem land we all talk to each other and are pretty good at working colaboratively, and it sounds like the MM team also has good internal communications. But we seem to have some problems with tackling issues that cross over between FS and MM land, or awkwardly sit between them. Perhaps this is something we could try to address when picking conference topics in the future. Johannes also mentioned a monthly group call the MM devs schedule - I wonder if it would be useful to get something similar going between MM and interested parties in filesystem land.
