Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1534019

Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3)

Show all headers | View raw

On 11/29/2016 09:17 PM, Dave Hansen wrote:
> Andrew, you can drop proc-mm-export-pte-sizes-directly-in-smaps-v2.patch,
> and replace it with this.
>
> Changes from v2:
>  * Do not assume (wrongly) that smaps_hugetlb_range() always uses
>    PUDs.  (Thanks for pointing this out, Vlastimil).  Also handle
>    hstates that are not exactly at PMD/PUD sizes.
>
> 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* instead?
>
> 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.
>
> Note: hugetlbfs PTEs are unusual.  We can have more than one "pte_t"
> for each hugetlbfs "page".  arm64 has this configuration, and probably
> others.  The code should now handle when an hstate's size is not equal
> to one of the page table entry sizes.  For instance, it assumes that
> hstates between PMD_SIZE and PUD_SIZE are made up of multiple PMDs
> and prints them as such.
>
> I've tested this on x86 with normal 4k ptes, anonymous huge pages,
> 1G hugetlbfs and 2M hugetlbfs pages.
>
> 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: Vlastimil Babka <vbabka@suse.cz>
> Cc: linux-mm@kvack.org
> Cc: linux-arch@vger.kernel.org

Acked-by: Vlastimil Babka <vbabka@suse.cz>

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] proc: mm: export PTE sizes directly in smaps (v3) Dave Hansen <dave@sr71.net> - 2016-11-29 21:20 +0100
  Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3) Vlastimil Babka <vbabka@suse.cz> - 2016-12-01 13:30 +0100
  Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3) Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-12-01 16:00 +0100
    Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3) Dave Hansen <dave@sr71.net> - 2016-12-10 00:20 +0100
  Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3) "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2016-12-02 16:50 +0100
  Re: [PATCH] proc: mm: export PTE sizes directly in smaps (v3) "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2016-12-02 19:10 +0100

csiph-web