Folios
2026-03-05
Edited: 2026-03-09
Physical Memory
Hardware allows memory to be mapped virtually as well as physically. Physical memory addresses tell where the memory exists physically while virtual memory essentially serves as an interface to the physical memory.
The hardware divides memory into chunks of size \(2^{n}\) physically continuous memory called pages. The base page is the smallest page size the hardware can work with. This one depends on the architecture.
The kernel used to have an actual struct page (around 64 bytes) storing the metadata of this page. So on a 64GB system with 4KB, it takes around 1GB or 1.6% of total memory. To find this,
- Find the number of pages: 64GB / (4e-6 GB)
- Multiply by 64 to get bytes required
- Convert this value to GB if desired
When we need more memory, such as applications which require operating in terms of physical memory (direct RAM access or Transparent Huge Pages (THP)), we need to describe the memory with more than one page struct.
Compound Pages
For multiple pages, we can use a separate struct which contains a continuous range of pages, which are called compound pages. The key metadata is in the first of these pages: the head page. The rest of the pages are tail pages. As usual, with most linked structures, there is wasted space. The article also points out the issue of determining whether a page is now
- a head page
- a tail page
- a compound page
There are functions throughout the kernel which operates on specific types of these pages, which means to differentiate between them, we need to dereference the head of the compound page first and then look it up.
Folios (Ottowa)
Folios were made to solve the variant issue above. Folios are just the struct page but guarantees a page is either a single page or the head of a compound page. This was great for performance.
Interestingly enough, folios do not deal with base page sizes, but explicitly deals with ranges of different sizes. This means
- page cache are not bounded by the 4 KB granularity
- filesystems are not limited by 4 KB block sizes
- reclaim (using folios) was faster as they were not limited to 4 KB
Essentially, working beyond the granularity generally allows utilizing the full IO of the given hardware, which might be capable of working beyond the 4 KB limit. Note that the 4 KB is not a set limit of the base page, but is a rather common number.
Folios also support mTHP (multi-size THP) which are basically the hardware allowing for page sizes larger than the base page size. These are referred to as huge pages. Support for mTHP might be possible without folios, but the author of the text seems to believe it will be very difficult or impossible. This is not the case with folios which can operate on multi-sizes as well as break themselves into smaller folios as well.
Folios (New York)
This implementation (by Johannes Weiner) reduces the size of folios from 64B to 8B by storing a memory descriptor (memdesc) which is either
- an encoding of the metadata in 8 byte
- pointer to separate structure which has the required information
However, the separate structure has to be allocated separately, but it is apparently fine since less memory are allocated across continuous physical pages.
Another interesting bit is that memory for struct page is for the kernel which cannot be reclaimed, which means the memory reduction from folios is really important.
References
By Lorenzo Stoakes. Taken from https://blogs.oracle.com/linux/intro-to-folios.