lkml.org 
[lkml]   [2016]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] proc: mm: export PTE sizes directly in smaps (v2)
From
Date
On 11/17/2016 01:28 AM, Dave Hansen wrote:
> Changes from v1:
> * Do one 'Pte' line per pte size instead of mashing on one line
> * Use PMD_SIZE for pmds instead of PAGE_SIZE, whoops
> * Wrote some Documentation/
>
> --
>
> /proc/$pid/smaps has a number of fields that are intended to imply the
> kinds of PTEs used to map memory. "AnonHugePages" obviously tells you
> how many PMDs are being used. "MMUPageSize" along with the "Hugetlb"
> fields tells you how many PTEs you have for a huge page.
>
> 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:
>
> DevicePages:
> DeviceHugePages:
> DeviceGiganticPages:
> DeviceGinormousPages:
>
> to unmuddle things when page sizes get mixed. That's fine, but
> it does require userspace know the mapping from our various
> arbitrary names to hardware page sizes on each architecture and
> kernel configuration. That seems rather suboptimal.
>
> What folks really want is to know how much memory is mapped with
> each page size. How about we just do *that*?
>
> Patch attached. Seems harmless enough. Seems to compile on a
> bunch of random architectures. Makes smaps look like this:
>
> Private_Hugetlb: 0 kB
> Swap: 0 kB
> SwapPss: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> Locked: 0 kB
> Ptes@4kB: 32 kB
> Ptes@2MB: 2048 kB
>
> 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.
>
> 1. I'd like to thank Dan Williams for showing me a mirror as I
> complained about the bozo that introduced 'AnonHugePages'.
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Cc: linux-mm@kvack.org

Hmm, why not, I guess. But are HugeTLBs handled correctly?

> @@ -702,11 +707,13 @@ static int smaps_hugetlb_range(pte_t *pt
> }
> if (page) {
> int mapcount = page_mapcount(page);
> + unsigned long hpage_size = huge_page_size(hstate_vma(vma));
>
> + mss->rss_pud += hpage_size;

This hardcoded pud doesn't look right, doesn't the pmd/pud depend on
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;
> }

\
 
 \ /
  Last update: 2016-11-24 15:23    [W:0.098 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site