[PATCH 18/31] powerpc/mm: Increase the pte frag size.

[Benjamin Herrenschmidt]

On Mon, 2015-09-21 at 14:15 +0530, Aneesh Kumar K.V wrote:
> Benjamin Herrenschmidt <benh at kernel.crashing.org> writes:
> 
> > On Mon, 2015-09-21 at 12:10 +0530, Aneesh Kumar K.V wrote:
> > > /*
> > > - * We use a 2K PTE page fragment and another 2K for storing
> > > - * real_pte_t hash index
> > > + * We use a 2K PTE page fragment and another 4K for storing
> > > + * real_pte_t hash index. Rounding the entire thing to 8K
> > >   */
> > 
> > Isn't this a LOT of memory wasted ? Page tables have a non
> > -negligible
> > footprint, we were already wasting half, now we are wasting 3/4 no
> > ?
> > 
> 
> The actual math is, we used to allocate 16 PTE page from a 64K page
> before. We now do 8 pte page from a 64K linux page.

Really ? I remember we were allocating exactly twice more, ie a 64K PTE
page was made of 32K of PTEs and 32K of extensions. I might not be
properly parsing either your above sentence or your comment, the way
you spell it it sounds like you are allocating now even more ...


> > Ie, in most cases on modern machines we never use the other
> > "half"...
> > 
> 
> That is true. We will use this only when we use 4K subpage. But I am
> not sure there is a better solution. Also, we should find this
> slightly
> imporve our contention on ptl lock. With SPLIT_PTLOCK we now have
> less
> number of pte page using the same spin lock.

You keep talking about "number of pte page" ... not sure what that
actually means.

In any case, shouldn't we consider something more like what we do for
subpage protection and just segregate the 4k stuff in a completely
separate tree which we can allocate on-demand so that we don't allocate
any of it if there is no demotion ?

Cheers,
Ben.

> -aneesh