Subject: Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v2)
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>,
        linux-kernel@vger.kernel.org
References: <20161117002851.C7BACB98@viggo.jf.intel.com>
 <5837B774.6060604@linux.vnet.ibm.com>
Cc: hch@lst.de, akpm@linux-foundation.org, dan.j.williams@intel.com,
        linux-mm@kvack.org
From: Dave Hansen <dave@sr71.net>
Message-ID: <4e792e57-c34c-1609-f637-33cf3b136851@sr71.net>
Date: Mon, 28 Nov 2016 09:00:10 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <5837B774.6060604@linux.vnet.ibm.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2689
Lines: 74

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.