On 11/24/2016 08:00 PM, Anshuman Khandual wrote:
...
>> The current mechanisms work fine when we have one or two page sizes.
>> But, they start to get a bit muddled when we mix page sizes inside
>> one VMA. For instance, the DAX folks were proposing adding a set of
>> fields like:
>
> So DAX is only case which creates this scenario of multi page sizes in
> the same VMA ? Is there any cases other than DAX mapping ?
Both file and anonymous huge pages. No other ones in the core VM that I
can think of.
>> DevicePages:
>> DeviceHugePages:
>> DeviceGiganticPages:
>> DeviceGinormousPages:
>
> I guess these are the page sizes supported at PTE, PMD, PUD, PGD level.
> Are all these page sizes supported right now or we are just creating
> place holder for future.
I know there are patches for PUD level support in DAX, but I don't think
they're merged yet. There is definitely *not* support for PGD level
since we don't have such support in hardware on x86 as far as I know.
>> SwapPss: 0 kB
>> KernelPageSize: 4 kB
>> MMUPageSize: 4 kB
>> Locked: 0 kB
>> Ptes@4kB: 32 kB
>> Ptes@2MB: 2048 kB
>
> So in the left column we are explicitly indicating the size of the PTE
> and expect the user to figure out where it can really be either at PTE,
> PMD, PUD etc. Thats little bit different that 'AnonHugePages' or the
> Shared_HugeTLB/Private_HugeTLB pages which we know are the the PMD/PUD
> level.
Yeah, it's a little different from what we have.
>> The format I used here should be unlikely to break smaps parsers
>> unless they're looking for "kB" and now match the 'Ptes@4kB' instead
>> of the one at the end of the line.
>
> Right. So you are dropping the idea to introduce these fields as you
> mentioned before for DAX mappings.
>
> DevicePages:
> DeviceHugePages:
> DeviceGiganticPages:
> DeviceGinormousPages:
Right. We don't need those if we have this patch.
>> if (page) {
>> int mapcount = page_mapcount(page);
>> + unsigned long hpage_size = huge_page_size(hstate_vma(vma));
>>
>> + mss->rss_pud += hpage_size;
>> if (mapcount >= 2)
>> - mss->shared_hugetlb += huge_page_size(hstate_vma(vma));
>> + mss->shared_hugetlb += hpage_size;
>> else
>> - mss->private_hugetlb += huge_page_size(hstate_vma(vma));
>> + mss->private_hugetlb += hpage_size;
>> }
>> return 0;
>
> Hmm, is this related to these new changes ? The replacement of 'hpage_size'
> instead of huge_page_size(hstate_vma(vma)) can be done in a separate patch.
Yes, this is theoretically unrelated, but I'm not breaking this 3-line
change up into a different patch unless there's a pretty good reason reason.
