Re: [PATCH 1/7] mm: Store compound_nr as well as compound_order

[Matthew Wilcox <willy@infradead.org>]

On Mon, Jul 06, 2020 at 01:29:25PM +0300, Kirill A. Shutemov wrote:
> On Mon, Jun 29, 2020 at 04:19:53PM +0100, Matthew Wilcox (Oracle) wrote:
> > This removes a few instructions from functions which need to know how many
> > pages are in a compound page.  The storage used is either page->mapping
> > on 64-bit or page->index on 32-bit.  Both of these are fine to overlay
> > on tail pages.
> 
> I'm not a fan of redundant data in struct page, even if it's less busy
> tail page. We tend to find more use of the space over time.
> 
> Any numbers on what it gives for typical kernel? Does it really worth it?

Oops, I overlooked this email.  Sorry.  Thanks to Andrew for the reminder.

I haven't analysed the performance win for this.  The assembly is
two instructions (11 bytes) shorter:

before:
    206c:       a9 00 00 01 00          test   $0x10000,%eax
    2071:       0f 84 af 02 00 00       je     2326 <shmem_add_to_page_cache.isra.0+0x3b6>
    2077:       41 0f b6 4c 24 51       movzbl 0x51(%r12),%ecx
    207d:       41 bd 01 00 00 00       mov    $0x1,%r13d
    2083:       49 8b 44 24 08          mov    0x8(%r12),%rax
    2088:       49 d3 e5                shl    %cl,%r13
    208b:       a8 01                   test   $0x1,%al

after:
    2691:       a9 00 00 01 00          test   $0x10000,%eax
    2696:       0f 84 95 01 00 00       je     2831 <shmem_add_to_page_cache.isr
a.0+0x291>
    269c:       49 8b 47 08             mov    0x8(%r15),%rax
    26a0:       45 8b 77 58             mov    0x58(%r15),%r14d
    26a4:       a8 01                   test   $0x1,%al

(there are other changes in these files, so the addresses aren't
meaningful).

If we need the space, we can always revert this patch.  It's all hidden
behind the macro anyway.