Re: [PATCH 0/3] Add PUD and kernel PTE level pagetable account

[Baolin Wang]

On 7/7/2022 10:44 PM, Dave Hansen wrote:
> On 7/7/22 04:32, Baolin Wang wrote:
> > On 7/6/2022 11:48 PM, Dave Hansen wrote:
> > > On 7/6/22 01:59, Baolin Wang wrote:
> > > > Now we will miss to account the PUD level pagetable and kernel PTE level
> > > > pagetable, as well as missing to set the PG_table flags for these
> > > > pagetable
> > > > pages, which will get an inaccurate pagetable accounting, and miss
> > > > PageTable() validation in some cases. So this patch set introduces new
> > > > helpers to help to account PUD and kernel PTE pagetable pages.
> > >
> > > Could you explain the motivation for this series a bit more?  Is there a
> > > real-world problem that this fixes?
> >
> > Not fix real problem. The motivation is that making the pagetable
> > accounting more accurate, which helps us to analyse the consumption of
> > the pagetable pages in some cases, and maybe help to do some empty
> > pagetable reclaiming in future.
>
> This accounting isn't free.  It costs storage (and also parts of
> cachelines) in each mm and CPU time to maintain it, plus maintainer
> eyeballs to maintain.  PUD pages are also fundamentally (on x86 at
> least) 0.0004% of the overhead of PTE and 0.2% of the overhead of PMD
> pages unless someone is using gigantic hugetlbfs mappings.

Yes, agree. However I think the performence influence of this patch is 
small from some testing I did (like mysql, no obvious performance 
influence). Moreover the pagetable accounting gap is about 1% from below 
testing data.

Without this patchset, the pagetable consumption is about 110M with 
mysql testing.
             flags      page-count       MB  symbolic-flags 
         long-symbolic-flags
0x0000000004000000           28232      110 
__________________________g__________________      pgtable

With this patchset, and the consumption is about 111M.
             flags      page-count       MB  symbolic-flags 
         long-symbolic-flags
0x0000000004000000           28459      111 
__________________________g__________________      pgtable


> Even with 1G gigantic pages, you would need a quarter of a million
> (well, 262144 or 512*512) mappings of one 1G page to consume 1G of
> memory on PUD pages.
>
> That just doesn't seem like something anyone is likely to actually do in
> practice.  That makes the benefits of the PUD portion of this series
> rather unclear in the real world.
>
> As for the kernel page tables, I'm not really aware of them causing any
> problems.  We have a pretty good idea how much space they consume from
> the DirectMap* entries in meminfo:
>
> 	DirectMap4k:     2262720 kB
> 	DirectMap2M:    40507392 kB
> 	DirectMap1G:    24117248 kB

However these statistics are arch-specific information, which only 
available on x86, s390 and powerpc.

> as well as our page table debugging infrastructure.  I haven't found
> myself dying for more specific info on them.
>
> So, nothing in this series seems like a *BAD* idea, but I'm not sure in
> the end it solves more problems than it creates.

Thanks for your input.