[lkml]   [2016]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] proc: mm: export PTE sizes directly in smaps (v2)
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.

 \ /
  Last update: 2016-11-28 18:01    [W:0.048 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site