Alexander H Duyck <alexander.duyck@xxxxxxxxx> wrote: > Also I have some concerns about going from page to folio as it seems > like the folio_alloc setups the transparent hugepage destructor instead > of using the compound page destructor. I would think that would slow > down most users as it looks like there is a spinlock that is taken in > the hugepage destructor that isn't there in the compound page > destructor. Note that this code is going to have to move to folios[*] at some point. "Old-style" compound pages are going to go away, I believe. Matthew Wilcox and the mm folks are on a drive towards simplifying memory management, formalising chunks larger than a single page - with the ultimate aim of reducing the page struct to a single, typed pointer. So, take, for example, a folio: As I understand it, this will no longer overlay struct page, but rather will become a single, dynamically-allocated struct that covers a pow-of-2 number of pages. A contiguous subset of page structs will point at it. However, rather than using a folio, we could define a "page fragment" memory type. Rather than having all the flags and fields to be found in struct folio, it could have just the set to be found in page_frag_cache. David [*] It will be possible to have some other type than "folio". See "struct slab" in mm/slab.h for example. struct slab corresponds to a set of pages and, in the future, a number of struct pages will point at it.
