nommu and folios

[Matthew Wilcox <willy@infradead.org>]

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 ;-)