Re: [PATCH v2] fs: proc: task_mmu: show page size in /proc/<pid>/numa_maps
From: Rafael Aquini
Date: Mon Jan 05 2015 - 19:21:51 EST
On Mon, Jan 05, 2015 at 03:20:37PM -0800, Andrew Morton wrote:
> On Mon, 5 Jan 2015 17:55:05 -0500 Rafael Aquini <aquini@xxxxxxxxxx> wrote:
>
> > On Mon, Jan 05, 2015 at 01:35:00PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Jan 2015 12:44:31 -0500 Rafael Aquini <aquini@xxxxxxxxxx> wrote:
> > >
> > > > This patch introduces 'kernelpagesize_kB' line element to /proc/<pid>/numa_maps
> > > > report file in order to help identifying the size of pages that are backing
> > > > memory areas mapped by a given task. This is specially useful to
> > > > help differentiating between HUGE and GIGANTIC page backed VMAs.
> > > >
> > > > This patch is based on Dave Hansen's proposal and reviewer's follow-ups
> > > > taken from the following dicussion threads:
> > > > * https://lkml.org/lkml/2011/9/21/454
> > >
> > > Dave's changelog contains useful information which this one lacked. I
> > > stole some of it.
> > >
> > > : The output of /proc/$pid/numa_maps is in terms of number of pages like
> > > : anon=22 or dirty=54. Here's some output:
> > > :
> > > : 7f4680000000 default file=/hugetlb/bigfile anon=50 dirty=50 N0=50
> > > : 7f7659600000 default file=/anon_hugepage\040(deleted) anon=50 dirty=50 N0=50
> > > : 7fff8d425000 default stack anon=50 dirty=50 N0=50
> > > : Looks like we have a stack and a couple of anonymous hugetlbfs
> > > : areas page which both use the same amount of memory. They don't.
> > > :
> > > : The 'bigfile' uses 1GB pages and takes up ~50GB of space. The
> > > : anon_hugepage uses 2MB pages and takes up ~100MB of space while the stack
> > > : uses normal 4k pages. You can go over to smaps to figure out what the
> > > : page size _really_ is with KernelPageSize or MMUPageSize. But, I think
> > > : this is a pretty nasty and counterintuitive interface as it stands.
> > > :
> > > : This patch introduces 'kernelpagesize_kB' line element to
> > > : /proc/<pid>/numa_maps report file in order to help identifying the size of
> > > : pages that are backing memory areas mapped by a given task. This is
> > > : specially useful to help differentiating between HUGE and GIGANTIC page
> > > : backed VMAs.
> > > :
> > > : This patch is based on Dave Hansen's proposal and reviewer's follow-ups
> > > : taken from the following dicussion threads:
> > > : * https://lkml.org/lkml/2011/9/21/454
> > > : * https://lkml.org/lkml/2014/12/20/66
> > >
> > >
> > > > + seq_printf(m, " kernelpagesize_kB=%lu", vma_kernel_pagesize(vma) >> 10);
> > >
> > > This changes the format of the numa_maps file and can potentially break
> > > existing parsers. Please discuss.
>
> ^^ ??
>
Sorry I overlooked it.
Parsers indeed would have to be adjusted to cope with an extra line element
(they already have to do so, similarly, for the conditional 'huge' hint).
Despite I don't think of it as a showstopper (as is), I think we can consider
moving it to EOL, if its actual printout position turns out to be an issue.
For instance, with this patch a numa_maps line would look like the following:
7ff965200000 default file=/anon_hugepage\040(deleted) huge kernelpagesize_kB=2048 anon=5 dirty=5 N0=5
or it could look like this, if we decide to switch kernelpagesize_kB position to EOL,
for the sake of parsers:
7ff965200000 default file=/anon_hugepage\040(deleted) huge anon=5 dirty=5 N0=5 kernelpagesize_kB=2048
Cheers,
-- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/