linux-kernel - Re: [PATCH 2/5] perf kmem: Analyze page allocator events also

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: <20150324001828.GJ2782@sejong>
Date:	Tue, 24 Mar 2015 09:18:28 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Joonsoo Kim <js1304@...il.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Minchan Kim <minchan@...nel.org>
Subject: Re: [PATCH 2/5] perf kmem: Analyze page allocator events also

On Tue, Mar 24, 2015 at 02:32:17AM +0900, Joonsoo Kim wrote:
> 2015-03-23 15:30 GMT+09:00 Namhyung Kim <namhyung@...nel.org>:
> > The perf kmem command records and analyze kernel memory allocation
> > only for SLAB objects.  This patch implement a simple page allocator
> > analyzer using kmem:mm_page_alloc and kmem:mm_page_free events.
> >
> > It adds two new options of --slab and --page.  The --slab option is
> > for analyzing SLAB allocator and that's what perf kmem currently does.
> >
> > The new --page option enables page allocator events and analyze kernel
> > memory usage in page unit.  Currently, 'stat --alloc' subcommand is
> > implemented only.
> >
> > If none of these --slab nor --page is specified, --slab is implied.
> >
> >   # perf kmem stat --page --alloc --line 10
> >
> >   -------------------------------------------------------------------------------------
> >    Page             | Total alloc (KB) | Hits     | Order | Migration type | GFP flags
> >   -------------------------------------------------------------------------------------
> >    ffffea0015e48e00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea0015e47400 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea001440f600 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea001440cc00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c6300 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c5c00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c5000 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c4f00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c4e00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ffffea00140c4d00 |               16 |        1 |     2 |    RECLAIMABLE |  00285250
> >    ...              | ...              | ...      | ...   | ...            | ...
> >   -------------------------------------------------------------------------------------
> 
> Tracepoint on mm_page_alloc print out pfn as well as pointer of struct page.
> How about printing pfn rather than pointer of struct page?

I'd really like to have pfn rather than struct page.  But I don't know
how to convert page pointer to pfn in userspace.

The output of tracepoint via $debugfs/tracing/trace file is generated
from kernel-side, so it can easily have pfn from page pointer.  But
tracepoint itself only saves page pointer and we need to convert/print
it in userspace.

Yes, perf script (or libtraceevent) shows pfn when printing those
events.  But that's bogus since it cannot determine the size of the
struct page so the pointer arithmetic in open-coded page_to_pfn()
which is saved in the print_fmt of the tracepoint will end up with an
normal integer arithmatic.

Do I miss something?

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/