On Sat, Oct 23, 2021 at 11:58:42AM +0200, David Hildenbrand wrote: > I know, the crowd is screaming "we want folios, we need folios, get out > of the way". I know that the *compound page* handling is a mess and that > we want something to change that. The point I am making is that folios > are not necessarily what we *need*. > > Types as discussed above are really just using the basic idea of a folio > lifted to the next level that not only avoid any kind of PageTail checks > but also any kind of type checks we have splattered all over the place. > IMHO that's a huge win when it comes to code readability and > maintainability. This also tackles the point Johannes made: folios being > the dumping ground for everything. And he has a point, because folios > are really just "not tail pages", so consequently they will 99% just > mimic what "struct page" does, and we all know what that means. Look, even if folios go this direction of being the compound page replacement, the "new dumping ground" argument is just completely bogus. In introducing new types and type safety for struct page, it's not reasonable to try to solve everything at once - we don't know what an ideal end solution is going to look like, we can't see that far ahead. What is a reasonable approach is looking for where the fault lines in the way struct page is used now, and cutting along those lines, look at the result, then cut it up some more. If the first new type still inherits most of the mess in struct page but it solves real problems, that's not a failure, that's normal incremental progress! -------- More than that, I think you and Johannes heard what I was saying about imagining what the ideal end solution would look like with infinite refactoring and you two have been running way too far with that idea - the stuff you guys are talking about sounds overengineered to me - inheritence heirarchies before we've introduced the first new type! The point of such thought experiments is to imagine how simple things could be - and also to not take such thought experiments too seriously, because when we start refactoring real world code, that's when we discover what's actually _possible_. I ran into a major roadblock when I tried converting buddy allocator freelists to radix trees: freeing a page may require allocating a new page for the radix tree freelist, which is fine normally - we're freeing a page after all - but not if it's highmem. So right now I'm not sure if getting struct page down to two words is even possible. Oh well. > Your patches introduce the concept of folio across many layers and your > point is to eventually clean up later and eventually remove it from all > layers again. I can understand that approach, yet I am at least asking > the question if this is the right order to do this. > > And again, I am not blocking this, I think cleaning up compound pages is > very nice. I'm asking questions to see how the concept of folios would > fit in long-term and if it would be required at all if types are done right. I'm also not really seeing the need to introduce folios as a replacement for all of compound pages, though - I think limiting it to file & anon and using the union-of-structs in struct page as the fault lines for introducing new types would be the reasonable thing to do. The struct slab patches were great, it's a real shame that the slab maintainers have been completely absent. Also introducing new types to be describing our current using of struct page isn't the only thing we should be doing - as we do that, that will (is!) uncover a lot of places where our ontology of struct page uses is just nonsensical (all the types of pages mapped into userspace!) - and part of our mission should be to clean those up. That does turn things into a much bigger project than what Matthew signed up for, but we shouldn't all be sitting on the sidelines here...
