On Mon, 2015-09-21 at 14:15 +0530, Aneesh Kumar K.V wrote: > Benjamin Herrenschmidt <b...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
