On Fri, Sep 17, 2021 at 03:24:40PM +1000, Dave Chinner wrote: > On Thu, Sep 16, 2021 at 12:54:22PM -0400, Johannes Weiner wrote: > > I agree with what I think the filesystems want: instead of an untyped, > > variable-sized block of memory, I think we should have a typed page > > cache desciptor. > > I don't think that's what fs devs want at all. It's what you think > fs devs want. If you'd been listening to us the same way that Willy > has been for the past year, maybe you'd have a different opinion. I was going off of Darrick's remarks about non-pagecache uses, Kent's remarks Kent about simple and obvious core data structures, and yes your suggestion of "cache page". But I think you may have overinterpreted what I meant by cache descriptor: > Indeed, we don't actually need a new page cache abstraction. I didn't suggest to change what the folio currently already is for the page cache. I asked to keep anon pages out of it (and in the future potentially other random stuff that is using compound pages). It doesn't have any bearing on how it presents to you on the filesystem side, other than that it isn't as overloaded as struct page is with non-pagecache stuff. A full-on disconnect between the cache entry descriptor and the page is something that came up during speculation on how the MM will be able to effectively raise the page size and meet scalability requirements on modern hardware - and in that context I do appreciate you providing background information on the chunk cache, which will be valuable to inform *that* discussion. But it isn't what I suggested as the immediate action to unblock the folio merge. > The fact that so many fs developers are pushing *hard* for folios is > that it provides what we've been asking for individually over last > few years. I'm not sure filesystem people are pushing hard for non-pagecache stuff to be in the folio. > Willy has done a great job of working with the fs developers and > getting feedback at every step of the process, and you see that in > the amount of work that in progress that is already based on > folios. And that's great, but the folio is blocked on MM questions: 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? 2. Are compound pages a scalable, future-proof allocation strategy? For some people the answers are yes, for others they are a no. For 1), the value proposition is to clean up the relatively recent head/tail page confusion. And though everybody agrees that there is value in that, it's a LOT of churn for what it does. Several people have pointed this out, and AFAICS this is the most common reason for people that have expressed doubt or hesitation over the patches. In an attempt to address this, I pointed out the cleanup opportunities that would open up by using separate anon and file folio types instead of one type for both. Nothing more. No intermediate thing, no chunk cache. Doesn't affect you. Just taking Willy's concept of type safety and applying it to file and anon instead of page vs compound page. - It wouldn't change anything for fs people from the current folio patchset (except maybe the name) - It would accomplish the head/tail page cleanup the same way, since just like a folio, a "file folio" could also never be a tail page - It would take the same solution folio prescribes to the compound page issue (explicit typing to get rid of useless checks, lookups and subtle bugs) and solve way more instances of this all over MM code, thereby hopefully boosting the value proposition and making *that part* of the patches a clearer win for the MM subsystem This is a question directed at MM people, not filesystem people. It doesn't pertain to you at all. And if MM people agree or want to keep discussing it, the relatively minor action item for the folio patch is the same: drop the partial anon-to-folio conversion bits inside MM code for now and move on. 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. We know there are multiple page sizes supported by the hardware and the smallest supported one is no longer the most dominant one. We do not know for sure yet how the MM is internally going to lay out its type system so that the allocator, mmap, page reclaim etc. can be CPU efficient and the descriptors be memory efficient. Nobody's "grand plan" here is any more viable, tested or proven than anybody else's. My question for fs folks is simply this: as long as you can pass a folio to kmap and mmap and it knows what to do with it, is there any filesystem relevant requirement that the folio map to 1 or more literal "struct page", and that folio_page(), folio_nr_pages() etc be part of the public API? Or can we keep this translation layer private to MM code? And will page_folio() be required for anything beyond the transitional period away from pages? Can we move things not used outside of MM into mm/internal.h, mark the transitional bits of the public API as such, and move on? The unproductive vitriol, personal attacks and dismissiveness over relatively minor asks and RFCs from the subsystem that is the most impacted by this patchset is just nuts.
