Re: nommu and folios

[Greg Ungerer <gerg@linux-m68k.org>]

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