Clarifying memory management with page folios

At the lowest level, pages are a concept implemented by the hardware; thetracking of memory and whether it is present in RAM or not is done at pagegranularity. Any given CPU architecture may offer alimited selection of page sizes, but one "base" page size must be chosen,and the most common choice remains 4,096 bytes — the same as it was whenthe first Linux kernels were released 30 years ago.

The kernel, though, often has reason to work with memory in larger chunks.One example is the management of "huge pages" which, once again, areimplemented by the hardware. The x86 architecture, for example, can work with 2MB hugepages, and there are performance advantages to using them where they areapplicable. The kernel will also allocate groups of pages in other sizes,though, typically for DMA buffers or other uses where a set of physicallycontiguous pages is needed. This sort of grouping of pages is known as a"compound page" in the kernel.

Every base page of memory managed by the kernel is represented by apage structure in the system memorymap. When a compound page is created out of a set of base pages, thepage structure for the first page in the set (the "head page") isspecially marked to make its compound nature explicit. The otherinformation in that structure refers to the compound page as a whole.All of the otherpages (the "tail pages") are marked as such, with a pointer to thepage structure for the associated head page. Seethis article for details on how compound pagesare organized.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll haveaccess to all of LWN’s high-quality articles as soon as they’republished, and help support LWN in the process.Act now and you can start with a free trial subscription.

This mechanism makes it easy to go from thepage structure of atail page to the head page for the compound page. Many interfaces withinthe kernel make use of that feature, but it creates a fundamentalambiguity: if a function is passed a pointer to apage structurefor a tail page, is it expected to act on that tail page or on the compoundpage as a whole? Or, as Wilcox put it inthefirst posting of the folio series in December:

A function which has a struct page argument might be expecting ahead or base page and will BUG if given a tail page. It might workwith any kind of page and operate on PAGE_SIZE bytes. It mightwork with any kind of page and operate on page_size() bytes ifgiven a head page but PAGE_SIZE bytes if given a base or tail page.It might operate on page_size() bytes if passed a head or tailpage. We have examples of all of these today.

(PAGE_SIZE is the size of a base page, whilepage_size()returns the full size of a — possibly compound — page.)There does not seem to be an extensive history of bugs resulting from thisparticular API, but an interface that is this poorly defined seems likelyto encourage problems sooner or later.

In an attempt to clarify the situation, Wilcox has come up with the conceptof a "page folio", which is really just apage structure that isguaranteed not to be a tail page. Any function accepting a folio willoperate on the full compound page (if, indeed, it is a compound page) withno ambiguity. The result is greater clarity in the kernel'smemory-management subsystem; as functions are converted to take folios asarguments, it will become clear that they are not meant to operate on tailpages.

When Wilcox first postedthis patch series, though, he emphasized a differentbenefit from the change. Any function that might be passed a tail page,but which must operate on the full compound page containing that tail page,must exchange any pointers to tail-pagepage structuresfor pointers to the head page instead. That is typically done with a callto:

    struct page *compound_head(struct page *page);

This function is relatively cheap, but it may be called many times over thecourse of a single operation on a page. That makes the kernel bigger(since it's an inline function) and slows things down. A function thataccepts a folio, instead, knows that it is not dealing with a tail page; thus it need not callcompound_head(). That saves both time andmemory.

The folio type itself is defined as a simple wrapper structure:

    struct folio {        struct page page;    };

From there, a new set of infrastructure is built up. For example,get_folio() andput_folio() will manage references to thefolio much likeget_page() andput_page(), but withoutthe unneeded calls tocompound_head(). A whole set ofhigher-level functions follows from there. Much of the real work, though,will be in converting various kernel subsystems to use the new type; Wilcoxdidn't sugarcoat the nature of that task:

This is going to be a ton of work, and massively disruptive. It'lltouch every filesystem, and a good few device drivers! But I thinkit's worth it.

By the time thefourthversion of this patch set was posted on March 5, the core patchesand the conversions (which Wilcox didn't post) added up to about 100commits, which is a fair amount to review.

Perhaps as a result of the size of the patch series, the previous postingsdid not elicit that much discussion. In response to the latest one,though, Andrew Mortontooka look and was worried by what he saw:

Geeze it's a lot of noise. More things to remember and we'llforever have a mismash of `page' and `folio' and code everywhereconverting from one to the other. Ongoing addition of folioaccessors/manipulators to overlay the existing pageaccessors/manipulators, etc.

It's unclear to me that it's all really worth it.

Hugh Dickins, too,expresseda lack of enthusiasm for this work. On the other hand,KirillShutemov andMichal Hockoboth expressed support for it, in concept at least. Dave Chinnersaidthat "this abstraction is absolutely necessary" for filesystemdevelopers, especially if and when the page cache gains the ability tomanage compound pages of multiple sizes.

So, in other words, there is currently no consensus among the coredevelopers regarding whether this work improves the kernel or not. Thatmay change over time as more people look at it and its advantages (or thelack thereof) become more clear. But change tends to happen slowly in thememory-management subsystem in general, even when the patch set in questionis not so large and messy. One should also bear in mind that there is aninevitable discussion on naming to be had; it is already clear that "folio"is not popular, though alternatives are currently thin on the ground. Oneconclusion is thus clear: thekernel may well get folios or something like them, but it seems unlikely tohappen soon.