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

Baolin Wang
2022-07-10T11:20:05Z

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.