Thread (96 messages) 96 messages, 6 authors, 2021-06-08

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.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help