linux-kernel - Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e792e57-c34c-1609-f637-33cf3b136851@sr71.net>
Date:   Mon, 28 Nov 2016 09:00:10 -0800
From:   Dave Hansen <dave@...1.net>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        linux-kernel@...r.kernel.org
Cc:     hch@....de, akpm@...ux-foundation.org, dan.j.williams@...el.com,
        linux-mm@...ck.org
Subject: Re: [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@...' 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.