Re: [PATCH v10 00/33] Memory folios
From: Matthew Wilcox <willy@infradead.org>
Date: 2021-06-04 02:13:49
Also in:
linux-fsdevel, lkml
On Fri, Jun 04, 2021 at 03:07:12AM +0200, Matteo Croce wrote:
On Tue, 11 May 2021 22:47:02 +0100 "Matthew Wilcox (Oracle)" [off-list ref] wrote:quoted
We also waste a lot of instructions ensuring that we're not looking at a tail page. Almost every call to PageFoo() contains one or more hidden calls to compound_head(). This also happens for get_page(), put_page() and many more functions. There does not appear to be a way to tell gcc that it can cache the result of compound_head(), nor is there a way to tell it that compound_head() is idempotent.Maybe it's not effective in all situations but the following hint to the compiler seems to have an effect, at least according to bloat-o-meter:
It definitely has an effect ;-)
Note that a function that has pointer arguments and examines the
data pointed to must _not_ be declared 'const' if the pointed-to
data might change between successive invocations of the function.
In general, since a function cannot distinguish data that might
change from data that cannot, const functions should never take
pointer or, in C++, reference arguments. Likewise, a function that
calls a non-const function usually must not be const itself.
So that's not going to work because a call to split_huge_page() won't
tell the compiler that it's changed.
Reading the documentation, we might be able to get away with marking the
function as pure:
The 'pure' attribute imposes similar but looser restrictions on a
function's definition than the 'const' attribute: 'pure' allows the
function to read any non-volatile memory, even if it changes in
between successive invocations of the function.
although that's going to miss opportunities, since taking a lock will
modify the contents of struct page, meaning the compiler won't cache
the results of compound_head().
$ scripts/bloat-o-meter vmlinux.o.orig vmlinux.o add/remove: 3/13 grow/shrink: 65/689 up/down: 21080/-198089 (-177009)
I assume this is an allyesconfig kernel? I think it's a good indication of how much opportunity there is.