On Sat, Oct 23, 2021 at 12:00:38PM -0400, Kent Overstreet wrote: > 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. I have a design in mind that I think avoids the problem. It's somewhat based on Bonwick's vmem paper, but not exactly. I need to write it up. > > 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. Right. Folios are for unspecialised head pages. If we decide to specialise further in the future, that's great! I think David misunderstood me slightly; I don't know that specialising file + anon pages (the aforementioned lru_mem) is the right approach. It might be! But it needs someone to try it, and find the advantages & disadvantages. > 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... I'm happy to help. Indeed I may take on some of these sub-projects myself. I just don't want the perfect to be the enemy of the good.
