nommu and folios

nommu and folios

[Matthew Wilcox]

Hi Greg!

The last user of add_to_page_cache_lru() is fs/ramfs/file-nommu.c I
think I need your advice about how best to proceed with nommu and folios.

The basic idea behind folios is that they represent a physically,
logically and virtually contiguous block of memory that is a power-of-2
bytes in size >= PAGE_SIZE.  struct page is going to be shrunk and it'll
be most efficient if we can arrange for allocations to be larger in size.

UCLinux obviously has very different performance requirements from the
kinds of systems I usually work on -- memory usage minimisation is much
more important.  So ideally we wouldn't split the allocation all the way
to order-0 in ramfs_nommu_expand_for_mapping(), but do a split at just
the break point.  eg if we have a 40kB file, we'd allocate an order-4
folio, split it into an order-3 folio and add that to the page cache;
split the order-2 page from the end and free it; split the remainder
into one order-1 folio, add it to the page cache and free the remaining
order-1 page.

The problem here is that all the code for handling large folios is
currently gated by CONFIG_TRANSPARENT_HUGEPAGE, which I'm guessing is
not enabled by any uclinux configs ;-)

Something I've been wanting to do for a while is split out the code
for handling PMD-sized folios from the code for splitting large folios
into smaller folios.  That's necessarily going to increase the size of
the text section for uclinux, but hopefully it'll be worthwhile because
it'll decrease how much memory is allocated at runtime.

Of course if uclinux files are typically PAGE_SIZE or smaller, this isn't
going to help at all.  Which brings me to the really sticky question
... how much do you care about uclinux support in a 2025 and later kernel?
I have no idea how actively microcontroller people use Linux or update
to recent kernels.  I'm not trying to push uclinux out, just don't want
to do work that nobody will ever use ;-)

Re: nommu and folios

[Greg Ungerer]

Hi Matthew,

On 15/7/25 05:22, Matthew Wilcox wrote:
> Hi Greg!
> 
> The last user of add_to_page_cache_lru() is fs/ramfs/file-nommu.c I
> think I need your advice about how best to proceed with nommu and folios.
> 
> The basic idea behind folios is that they represent a physically,
> logically and virtually contiguous block of memory that is a power-of-2
> bytes in size >= PAGE_SIZE.  struct page is going to be shrunk and it'll
> be most efficient if we can arrange for allocations to be larger in size.
> 
> UCLinux obviously has very different performance requirements from the
> kinds of systems I usually work on -- memory usage minimisation is much
> more important.  So ideally we wouldn't split the allocation all the way
> to order-0 in ramfs_nommu_expand_for_mapping(), but do a split at just
> the break point.  eg if we have a 40kB file, we'd allocate an order-4
> folio, split it into an order-3 folio and add that to the page cache;
> split the order-2 page from the end and free it; split the remainder
> into one order-1 folio, add it to the page cache and free the remaining
> order-1 page.
> 
> The problem here is that all the code for handling large folios is
> currently gated by CONFIG_TRANSPARENT_HUGEPAGE, which I'm guessing is
> not enabled by any uclinux configs ;-)

Yeah, pretty sure that is right :-)
Interestingly there is one architecture that is by default 64bit, RISCV.
It has good support for running nommu. Though I don't think in practice
that you would see nommu systems using it with largish memory sizes.
Even then I doubt they would be using TRANSPARENT HUPGEPAGES either.


> Something I've been wanting to do for a while is split out the code
> for handling PMD-sized folios from the code for splitting large folios
> into smaller folios.  That's necessarily going to increase the size of
> the text section for uclinux, but hopefully it'll be worthwhile because
> it'll decrease how much memory is allocated at runtime.

That sounds like a win overall. Anyone using modern kernels on nommu
has to accept the ever increasing kernel text section anyway.


> Of course if uclinux files are typically PAGE_SIZE or smaller, this isn't
> going to help at all.

Average file size is probably larger than PAGE_SIZE. All the standard
application binaries will be much larger.


>  Which brings me to the really sticky question
> ... how much do you care about uclinux support in a 2025 and later kernel?
> I have no idea how actively microcontroller people use Linux or update
> to recent kernels.  I'm not trying to push uclinux out, just don't want
> to do work that nobody will ever use ;-)

That is really hard to answer. My gut feeling is that it may not be used
that much any more. But then I keep getting surprised when people show up
with new silicon that has no MMU (RISCV being a case in point). From what
I can tell it is still popular with the ARM/Cortex-M variants as well.
Not really sure about the Xtensa community, they may be active too.

Regards
Greg