On Mon, Mar 22, 2021 at 12:52:40PM +1000, Nicholas Piggin wrote:

Excerpts from Matthew Wilcox's message of March 19, 2021 11:25 am:

quoted

On Fri, Mar 19, 2021 at 10:56:45AM +1100, Balbir Singh wrote:

quoted

On Fri, Mar 05, 2021 at 04:18:37AM +0000, Matthew Wilcox (Oracle) wrote:

quoted

A struct folio refers to an entire (possibly compound) page.  A function
which takes a struct folio argument declares that it will operate on the
entire compound page, not just PAGE_SIZE bytes.  In return, the caller
guarantees that the pointer it is passing does not point to a tail page.

Is this a part of a larger use case or general cleanup/refactor where
the split between page and folio simplify programming?

The goal here is to manage memory in larger chunks.  Pages are now too
small for just about every workload.  Even compiling the kernel sees a 7%
performance improvement just by doing readahead using relatively small
THPs (16k-256k).  You can see that work here:
https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/master

The 7% improvement comes from cache cold kbuild by improving IO
patterns?

Just wondering what kind of readahead is enabled by this that can't
be done with base page size.

I see my explanation earlier was confusing.  What I meant to say
was that the only way in that patch set to create larger pages was
at readahead time.  Writes were incapable of creating larger pages.
Once pages were in the page cache, they got managed at that granularity
unless they got split by a truncate/holepunch/io-error/...

I don't have good perf runs of kernbench to say exactly where we got the
benefit.  My assumption is that because we're managing an entire, say,
256kB page as a single unit on the LRU list, we benefit from lower LRU
lock contention.  There's also the benefit of batching, eg, allocating
a single 256kB page from the page allocator may well be more effective
than allocating 64 4kB pages.