From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
David Ahern <dsahern@gmail.com>, Minchan Kim <minchan@kernel.org>,
Joonsoo Kim <js1304@gmail.com>,
linux-mm@kvack.org
Subject: [PATCHSET 0/9] perf kmem: Implement page allocation analysis (v6)
Date: Mon, 6 Apr 2015 14:36:07 +0900 [thread overview]
Message-ID: <1428298576-9785-1-git-send-email-namhyung@kernel.org> (raw)
Hello,
Currently perf kmem command only analyzes SLAB memory allocation. And
I'd like to introduce page allocation analysis also. Users can use
--slab and/or --page option to select it. If none of these options
are used, it does slab allocation analysis for backward compatibility.
* changes in v6)
- add -i option fix (Jiri)
- libtraceevent operator priority fix
* changes in v5)
- print migration type and gfp flags in more compact form (Arnaldo)
- add kmem.default config option
* changes in v4)
- use pfn instead of struct page * in tracepoints (Joonsoo, Ingo)
- print gfp flags in human readable string (Joonsoo, Minchan)
* changes in v3)
- add live page statistics
* changes in v2)
- Use thousand grouping for big numbers - i.e. 12345 -> 12,345 (Ingo)
- Improve output stat readability (Ingo)
- Remove alloc size column as it can be calculated from hits and order
Patch 1 is to convert tracepoint to save pfn instead of struct page *.
Patch 2 implements basic support for page allocation analysis, patch 3
deals with the callsite and patch 4 implements sorting. Patch 5
introduces live page analysis which is to focus on currently allocated
pages only. Finally patch 6 prints gfp flags in human readable string.
In this patchset, I used two kmem events: kmem:mm_page_alloc and
kmem_page_free for analysis as they can track almost all of memory
allocation/free path AFAIK. However, unlike slab tracepoint events,
those page allocation events don't provide callsite info directly. So
I recorded callchains and extracted callsites like below:
Normal page allocation callchains look like this:
360a7e __alloc_pages_nodemask
3a711c alloc_pages_current
357bc7 __page_cache_alloc <-- callsite
357cf6 pagecache_get_page
48b0a prepare_pages
494d3 __btrfs_buffered_write
49cdf btrfs_file_write_iter
3ceb6e new_sync_write
3cf447 vfs_write
3cff99 sys_write
7556e9 system_call
f880 __write_nocancel
33eb9 cmd_record
4b38e cmd_kmem
7aa23 run_builtin
27a9a main
20800 __libc_start_main
But first two are internal page allocation functions so it should be
skipped. To determine such allocation functions, I used following regex:
^_?_?(alloc|get_free|get_zeroed)_pages?
This gave me a following list of functions (you can see this with -v):
alloc func: __get_free_pages
alloc func: get_zeroed_page
alloc func: alloc_pages_exact
alloc func: __alloc_pages_direct_compact
alloc func: __alloc_pages_nodemask
alloc func: alloc_page_interleave
alloc func: alloc_pages_current
alloc func: alloc_pages_vma
alloc func: alloc_page_buffers
alloc func: alloc_pages_exact_nid
After skipping those function, it got '__page_cache_alloc'.
Other information such as allocation order, migration type and gfp
flags are provided by tracepoint events.
Basically the output will be sorted by total allocation bytes, but you
can change it by using -s/--sort option. The following sort keys are
added to support page analysis: page, order, mtype, gfp. Existing
'callsite', 'bytes' and 'hit' sort keys also can be used.
An example follows:
# perf kmem record --page sleep 5
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 1.065 MB perf.data (2949 samples) ]
# perf kmem stat --page --caller -l 10
# GFP flags
# ---------
# 00000010: GFP_NOIO
# 000000d0: GFP_KERNEL
# 00000200: GFP_NOWARN
# 000052d0: GFP_KERNEL|GFP_NOWARN|GFP_NORETRY|GFP_COMP
# 000084d0: GFP_KERNEL|GFP_REPEAT|GFP_ZERO
# 000200d0: GFP_USER
# 000200d2: GFP_HIGHUSER
# 000200da: GFP_HIGHUSER_MOVABLE
# 000280da: GFP_HIGHUSER_MOVABLE|GFP_ZERO
# 002084d0: GFP_KERNEL|GFP_REPEAT|GFP_ZERO|GFP_NOTRACK
# 0102005a: GFP_NOFS|GFP_HARDWALL|GFP_MOVABLE
---------------------------------------------------------------------------------------------------------
Total alloc (KB) | Hits | Order | Migration type | GFP flags | Callsite
---------------------------------------------------------------------------------------------------------
16 | 1 | 2 | UNMOVABLE | 000052d0 | alloc_skb_with_frags
24 | 3 | 1 | UNMOVABLE | 000052d0 | alloc_skb_with_frags
3,876 | 969 | 0 | MOVABLE | 000200da | shmem_alloc_page
972 | 243 | 0 | UNMOVABLE | 000000d0 | __pollwait
624 | 156 | 0 | MOVABLE | 0102005a | __page_cache_alloc
304 | 76 | 0 | UNMOVABLE | 000200d0 | dma_generic_alloc_coherent
108 | 27 | 0 | MOVABLE | 000280da | handle_mm_fault
56 | 14 | 0 | UNMOVABLE | 002084d0 | pte_alloc_one
24 | 6 | 0 | MOVABLE | 000200da | do_wp_page
16 | 4 | 0 | UNMOVABLE | 00000200 | __tlb_remove_page
... | ... | ... | ... | ... | ...
---------------------------------------------------------------------------------------------------------
SUMMARY (page allocator)
========================
Total allocation requests : 1,518 [ 6,096 KB ]
Total free requests : 1,431 [ 5,748 KB ]
Total alloc+freed requests : 1,330 [ 5,344 KB ]
Total alloc-only requests : 188 [ 752 KB ]
Total free-only requests : 101 [ 404 KB ]
Total allocation failures : 0 [ 0 KB ]
Order Unmovable Reclaimable Movable Reserved CMA/Isolated
----- ------------ ------------ ------------ ------------ ------------
0 351 . 1,163 . .
1 3 . . . .
2 1 . . . .
3 . . . . .
4 . . . . .
5 . . . . .
6 . . . . .
7 . . . . .
8 . . . . .
9 . . . . .
10 . . . . .
I have some idea how to improve it. But I'd also like to hear other
idea, suggestion, feedback and so on.
This is available at perf/kmem-page-v6 branch on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Thanks,
Namhyung
Jiri Olsa (1):
perf kmem: Respect -i option
Namhyung Kim (8):
tracing, mm: Record pfn instead of pointer to struct page
perf kmem: Analyze page allocator events also
perf kmem: Implement stat --page --caller
perf kmem: Support sort keys on page analysis
perf kmem: Add --live option for current allocation stat
perf kmem: Print gfp flags in human readable string
perf kmem: Add kmem.default config option
tools lib traceevent: Honor operator priority
include/trace/events/filemap.h | 8 +-
include/trace/events/kmem.h | 42 +-
include/trace/events/vmscan.h | 8 +-
tools/lib/traceevent/event-parse.c | 17 +-
tools/perf/Documentation/perf-kmem.txt | 19 +-
tools/perf/builtin-kmem.c | 1302 ++++++++++++++++++++++++++++++--
6 files changed, 1307 insertions(+), 89 deletions(-)
--
2.3.2
next reply other threads:[~2015-04-06 5:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-06 5:36 Namhyung Kim [this message]
2015-04-06 5:36 ` [PATCH 1/9] perf kmem: Respect -i option Namhyung Kim
2015-04-08 15:11 ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-04-06 5:36 ` [PATCH 2/9] tracing, mm: Record pfn instead of pointer to struct page Namhyung Kim
2015-04-14 12:16 ` [tip:perf/urgent] " tip-bot for Namhyung Kim
2015-04-06 5:36 ` [PATCH 3/9] perf kmem: Analyze page allocator events also Namhyung Kim
2015-04-10 21:06 ` Arnaldo Carvalho de Melo
2015-04-10 21:10 ` Arnaldo Carvalho de Melo
2015-04-13 6:59 ` Namhyung Kim
2015-04-13 13:21 ` Arnaldo Carvalho de Melo
2015-04-13 13:40 ` Arnaldo Carvalho de Melo
2015-04-14 12:17 ` [tip:perf/urgent] " tip-bot for Namhyung Kim
2015-04-06 5:36 ` [PATCH 4/9] perf kmem: Implement stat --page --caller Namhyung Kim
2015-04-13 13:40 ` Arnaldo Carvalho de Melo
2015-04-14 2:17 ` Namhyung Kim
2015-04-06 5:36 ` [PATCH 5/9] perf kmem: Support sort keys on page analysis Namhyung Kim
2015-04-06 5:36 ` [PATCH 6/9] perf kmem: Add --live option for current allocation stat Namhyung Kim
2015-04-06 5:36 ` [PATCH 7/9] perf kmem: Print gfp flags in human readable string Namhyung Kim
2015-04-06 5:36 ` [PATCH 8/9] perf kmem: Add kmem.default config option Namhyung Kim
2015-04-06 5:36 ` [PATCH 9/9] tools lib traceevent: Honor operator priority Namhyung Kim
2015-04-06 14:45 ` Steven Rostedt
2015-04-07 7:52 ` Namhyung Kim
2015-04-07 13:02 ` Arnaldo Carvalho de Melo
2015-04-07 13:57 ` Steven Rostedt
2015-04-07 14:10 ` Namhyung Kim
2015-04-08 15:11 ` [tip:perf/core] " tip-bot for Namhyung Kim
2015-04-13 13:41 ` [PATCH 9/9] " Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1428298576-9785-1-git-send-email-namhyung@kernel.org \
--to=namhyung@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=mingo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).