LWN: Comments on "Clarifying memory management with page folios"

Clarifying memory management with page folios

fest3er — Wed, 26 Mar 2025 15:42:10 +0000

Late, but have to add me tuppence, recalling the proverbial bit bucket that sat on the floor next to mainframes of old.

'Bucket-o-bytes', which shortens to 'bob'.

And Bob's yer uncle.

OK. Maybe not.

Clarifying memory management with page folios

mpr22 — Sat, 16 Oct 2021 10:24:55 +0000

Indeed, almost nobody in the Anglosphere is going to think of a word from any of the languages of China when they see "juan".

If anything comes to mind at all, it's most likely to be the Spanish form of the Hebrew name יוֹחָנָן‎ (Yôḥānān), equivalent to English John, German Johann, Russian Иван, French Jean, etc.

Clarifying memory management with page folios

hidave — Sat, 16 Oct 2021 09:05:05 +0000

Another recommendation maybe not known in English world : juan, it means something like "volume"
https://en.wikipedia.org/wiki/Juan

Clarifying memory management with page folios

ncm — Thu, 16 Sep 2021 08:10:08 +0000

Names need to be long enough to distinguish the thing named from other things it might otherwise have been and (if you exercise any foresight) also things it will not be.

How long that name needs to be depends on the scope of the names.

In C, lacking any mechanism for namespacing, a practical name *often* must be unpleasantly long. That is a fault of the language, not (usually) of the person choosing the name; although some people confuse names with specifications, and so invent stupidly long names.

"Compound_page" is not, in any universe, stupidly long for a C struct tag.

Clarifying memory management with page folios

deepfire — Sun, 12 Sep 2021 09:37:32 +0000

Bingo!

..and it's surprising how much resistance does this encounter, given the improvements.

Clarifying memory management with page folios

taladar — Tue, 03 Aug 2021 08:40:26 +0000

Sounds like folio is basically what Haskell or Rust would call a newtype over page that indicates that certain precondition checks have already been performed.

Clarifying memory management with page folios

DavideRepetto — Tue, 15 Jun 2021 12:23:23 +0000

How about "bundle"?

Clarifying memory management with page folios

Hi-Angel — Fri, 02 Apr 2021 11:13:00 +0000

> Honestly, I'm 120 patches in at this point. Someone's going to have to be really convincing to have a better name than folio.

A little trick: doing a rename over all of the 120 patches might be done in just under a minute ;) What I'd do here is:

```
git format-patch -120 --stdout > 1.patch
sp folio my_better_name
git am -3 1.patch
```

Read `sp` as `sed`.

For the sake of completeness: sp is my alias to sed_perl, which in turn is a wrapper over perl to replace text in files https://github.com/Hi-Angel/dotfiles/blob/140c78951502754... I was at some point annoyed by discrepancies in behavior between grep, sed, awk, and what not, and migrated to using perl + ack (a perl version of grep). Never looked back.

So… hopefully this will help.

Clarifying memory management with page folios

flussence — Thu, 25 Mar 2021 23:00:04 +0000

7% is pretty impressive, considering that getting any performance improvement out of the mm code in this day and age is like drawing blood from a stone!

I vaguely remember getting excited over the original THP patchset because I'd measured a consistent 3-4% improvement in memory-heavy workloads…

Clarifying memory management with page folios

milesrout — Mon, 22 Mar 2021 23:48:17 +0000

It doesn't matter one bit which year it is. This "oh my god it's 2021 come on people" attitude is really silly. Long names are inconvenient to read and to write, and encourage code to be split over many lines to fit regardless of how many years it's been since Jesus was born.

Clarifying memory management with page folios

kiryl — Sun, 21 Mar 2021 20:38:58 +0000

It is not a compound page, but rather a head of compound page or a non-compound page. Compound page would be totally misleading.

Clarifying memory management with page folios

clugstj — Fri, 19 Mar 2021 17:16:55 +0000

Well then, I must respectfully disagree. IMO, the obvious name should not be ignored because it is "too long". This is not the 1960s, we can afford clarity of naming in code.

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 17:02:39 +0000

Because that's an extra 9 characters over 'struct page'. Short is generally better for something that's common.

Clarifying memory management with page folios

clugstj — Fri, 19 Mar 2021 17:01:11 +0000

Why not?

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 16:57:20 +0000

Are you suggesting calling it 'struct compound_page'?

Clarifying memory management with page folios

clugstj — Fri, 19 Mar 2021 14:08:01 +0000

I'm confused. It's a compound page, why not call it compound_page?

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 11:29:05 +0000

Have you looked at the patch series? I don't do everything in one go. Essentially I'm going one function at a time. It's pretty straightforward to convert between pages and folios. If you have a page and want the folio that contains it, that's spelled page_folio(page). If you have a folio and want the head page, that's &folio->page. If you have a folio and want the page that corresponds to a particular file index, that's folio_file_page(folio, index).

If you have a folio and want the n'th page, that's nth_page(&folio->page, n). Nobody's needed that one yet (and only people with really weird physical memory layouts need to do that ... alloc_folio() won't return a folio that you need to do that to. Others are working on maybe disallowing those from existing entirely, in which case (&folio->page + n) will do fine.

The performance improvements do not come from a small subset of the changes. You have to make the entire filesystem safe to handle memory in folios (no more references to, eg, PAGE_SIZE, unless you can prove they're safe, calls to kmap() have to be scrutinised. copy_(to|from)_iter() calls need care and attention, etc, etc). Once the filesystem declares itself safe by setting a bit in the fs_flags then the page cache can start handing it folios instead of pages.

I think what you're suggesting is essentially what I did here:
https://git.infradead.org/users/willy/pagecache.git/short...

I've given up on that approach because it's hard to find all the bugs. "Oh this interface takes a struct page. Does it take any struct page, or do I need to call it once for each tail page in the compound page?" I invite you to consider the various implementations of flush_dcache_page() ... and if you can figure out the answer, please let me know.

Clarifying memory management with page folios

geert — Fri, 19 Mar 2021 11:17:44 +0000

Thanks, folio is fine! ;-)

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 11:10:42 +0000

Aigle is a French paper size: https://en.wikipedia.org/wiki/Paper_size

https://en.wikipedia.org/wiki/Units_of_paper_quantity is also a good source of names.

Honestly, I'm 120 patches in at this point. Someone's going to have to be really convincing to have a better name than folio.

Clarifying memory management with page folios

geert — Fri, 19 Mar 2021 09:32:09 +0000

As a non-native English speaker, I had to look up most of the rejected options, so IMHO they must be fairly obscure...

BTW, "aigle" is not known by "dict", nor by my paper dictionary.

Clarifying memory management with page folios

wahern — Fri, 19 Mar 2021 09:12:35 +0000

Rather than doing everything in one go, couldn't a transparent union argument type and _Generic be used, variously, for certain critical functions and highly-trafficked interfaces? I image much of the performance improvements come from a relatively small subset of the changes. Those could be nailed down in a smaller patch series, and the remainder fixed over time.

Clarifying memory management with page folios

jonas.bonn — Fri, 19 Mar 2021 04:38:39 +0000

I like the name folio, but as a North American it's just got Shakespeare written all over it and has little intrinsic meaning; I understand where the reluctance towards the name is coming from...

Normally, pages are created by folding a 'sheet'... so there you go!

https://en.wikipedia.org/wiki/Paper_size#/media/File:A_si...

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 04:10:07 +0000

New version of patch series:

https://git.infradead.org/users/willy/pagecache.git/short...

I'll do the changelog / cover letter / ... in the morning.

BTW, I do want to emphasize that real workloads see a performance improvement. With the previous work, based on using Transparent Huge Pages, we saw a 7% performance improvement on kernel compiles, and that was with a very naive untuned algorithm for scaling up the THP size.

Clarifying memory management with page folios

guillemj — Fri, 19 Mar 2021 03:21:52 +0000

Ah, that brought up old memories of viengoos (https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;...).

Clarifying memory management with page folios

willy — Fri, 19 Mar 2021 03:17:03 +0000

I threw out a bunch of options early on: ream, sheaf and album didn't make it. Nor did quarto, aigle, quire, leaf, octavo or any number of other options ;-)

https://lore.kernel.org/linux-fsdevel/20201113174409.GH17...

Criteria: Must be easily greppable (book is bad), must be short, shouldn't be too cutesy (banqyet by analogy with byte was not under consideration).

Online thesauri are your friends, but at the end of the day it's always a matter of taste.

Clarifying memory management with page folios

unixbhaskar — Thu, 18 Mar 2021 21:47:47 +0000

Okay, I have had the uncanny habit of touching the triviality and it reflects on my work ...anyway...this point in the article :

"One should also bear in mind that there is an inevitable discussion on naming to be had; it is already clear that "folio" is not popular, though alternatives are currently thin on the ground. One conclusion is thus clear: the kernel may well get folios or something like them, but it seems unlikely to happen soon."

Matthew and Jon, how about a simple name(well, kernel is a bloody complex thing, it doesn't mean, it has to have a complex or artistic name,does it?) like "page_access" ? (I am sure that I missed certain things, a plethora of kernel API/ABI should have checked before preaching ...:) , which I haven't done so. But ......

Stop fretting at my naivety .... :) ..please...

Clarifying memory management with page folios

mathstuf — Thu, 18 Mar 2021 20:14:22 +0000

I like "ream" personally. Not sure if that's come up in the discussion already.

Clarifying memory management with page folios

logang — Thu, 18 Mar 2021 17:24:45 +0000

I thought the folio name was rather clever as the definition is a great fit. But maybe clever isn't always a good thing.

In any case, if it gets in as named, it's only a matter of time before we can start describing compound pages as foliolate (having compound leaves) and someone is sure to come up with a case for a 'struct portfolio'. ;-)