A discussion on folios

Posted Sep 23, 2021 22:23 UTC (Thu) by dullfire (guest, #111432)
Parent article: A discussion on folios

I've not looked over the folio or MM code, but it sounds kind of like there is a push to get filesystems to support different/larger page size?
As someone who regularly uses a POWER9 with 64K pages, that is an exciting prospect.

I also think breaking any expectations of homogeneous 4K pages would be beneficial to the overall code quality.

A discussion on folios

Posted Sep 23, 2021 22:52 UTC (Thu) by willy (subscriber, #9762) [Link] (1 responses)

You have it in a nutshell.

One thing that may intrigue you is the possibility of using 64k TLB entries on a kernel built with 4k page size. That will cut down on the amount of memory wasted caching small files.

We're a ways off being able to do that; there's no infrastructure in place to allow architectures to do that, but PPC and ARM are on my list as architectures of interest.

A discussion on folios

Posted Sep 24, 2021 0:04 UTC (Fri) by opalmirror (subscriber, #23465) [Link]

A coworker and I at Wind River designed and implemented a revision of the VxWorks MMU manager back around 2005 to make use of the TLB support for larger order pages in PowerPC 440GP, E500, MIPS and ARM - which had software managed TLBs - the main point having one MMU library that worked across multiple architectures, with plugins to adapt it to the capability of different CPUs and architectures and dynamically handle support for different TLB page sizes. If there were larger order page sizes than 4kbytes supported by the TLB caches (for example PPC440 can do 16k, 64k, 256k, 1M, 4M, 16M, etc.), then it can use them with only a little modification and setup - I wrote code to manage the larger order page sizes. This greatly reduced TLB misses for large dynamically loaded text regions and large memory mapped peripheral devices. It made memory mapped text with less severe performance degradation everywhere, especially on small MIPS 4k or PowerPC 405GP processors with meager TLB slots but available large order page sizes. I remember talking about this strategy at some length with Rik Van Riel back at Ottawa Linux Symposium around that time, when I started working on WRLinux full time. Much easier to implement a memory manager for a simple RTOS like VxWorks than for all the various workloads of Linux, but I'm glad to see related work starting to happen now. Appreciating your effort, Matthew.