Re: [PATCH v10 00/33] Memory folios

[Matthew Wilcox]

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)" <willy@xxxxxxxxxxxxx> wrote:
> 
> > 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.