From: Hou Pengyang <houpengyang@huawei.com>
To: <acme@kernel.org>, <mingo@redhat.com>, <namhyung@kernel.org>,
<a.p.zijlstra@chello.nl>
Cc: <wangnan0@huawei.com>, <linux-kernel@vger.kernel.org>,
<zhu.wen-jie@hp.com>
Subject: Re: [RFC] perf tools: Add hugetlbfs memory recognition
Date: Sat, 27 Jun 2015 17:08:20 +0800 [thread overview]
Message-ID: <558E6804.5060602@huawei.com> (raw)
In-Reply-To: <1435394953-146405-1-git-send-email-houpengyang@huawei.com>
On 2015/6/27 16:49, Hou Pengyang wrote:
> Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
> What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
> (%d = pid of process), and perf would parse symbol located in this area
> according to /tmp/perf-%d.map. It works well for normal mmap.
>
> However, when we alloc such memory from hugetlbfs by the following code:
>
> ......
>
> fd = open("/mnt/huge/hugepagefile", O_CREAT | O_RDWR, 0755);
> if (fd < 0) {
> perror("Open failed");
> exit(1);
> }
> addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \
> PROT_EXEC, MAP_SHARED, fd, 0);
>
> ......
> where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:
>
> #perf report
> 86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffffffe00000005c
> 86.96% 0.00% hugepage-mmap hugepagefile [.] 0xffffffe0000000ac
>
> This is because such mmap area's file backed is "/mnt/huge/hugepagefile", a node
> in pseudo filesystem, it is useless for symbol-parsing. so wo had better recognize
> such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as anon-memory
> and no_dso_memory do.
>
> This patch imports a new function named is_hugetlb_memory to check if this memory
> is from hugetlbfs. If true, change its name.
>
> After this patch:
> #perf report
> 86.96% 0.00% hugepage-mmap perf-182.map [.] 0x000000200000005c
> 86.96% 0.00% hugepage-mmap perf-182.map [.] 0x00000020000000ac
>
> We can add maps info to perf-182.map for further symbols-parsing.
>
> Signed-off-by: Hou Pengyang <houpengyang@huawei.com>
> ---
> tools/perf/util/map.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index b5a5e9c..796db08 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -15,6 +15,7 @@
> #include "debug.h"
> #include "machine.h"
> #include <linux/string.h>
> +#include <sys/mman.h>
>
> static void __maps__insert(struct maps *maps, struct map *map);
>
> @@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
> !strncmp(filename, "/system/lib", 11);
> }
>
> +static inline int is_hugetlb_memory(u32 flags)
> +{
> + return flags & MAP_HUGETLB;
> +}
There is something about MAP_HUGETLB.
In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.
However, if mmap area is hugetlb related, MAP_HUGETLB does not always
appear. Because, there are two ways generating MMAP2 event.
1) when a new vm_area_struct is created, its info would be exported
as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.
MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).
This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
details appear in /proc/pid/smaps, such as MAP_HUGETLB.
So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem
by another way?
Thanks!
> +
> static inline bool replace_android_lib(const char *filename, char *newfilename)
> {
> const char *libname;
> @@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start, u64 len,
> if (map != NULL) {
> char newfilename[PATH_MAX];
> struct dso *dso;
> - int anon, no_dso, vdso, android;
> + int anon, no_dso, vdso, android, hugetlb;
>
> android = is_android_lib(filename);
> anon = is_anon_memory(filename);
> vdso = is_vdso_map(filename);
> no_dso = is_no_dso_memory(filename);
> + hugetlb = is_hugetlb_memory(flags);
>
> map->maj = d_maj;
> map->min = d_min;
> @@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start, u64 len,
> map->prot = prot;
> map->flags = flags;
>
> - if ((anon || no_dso) && type == MAP__FUNCTION) {
> + if ((anon || no_dso || hugetlb) && type == MAP__FUNCTION) {
> snprintf(newfilename, sizeof(newfilename), "/tmp/perf-%d.map", pid);
> filename = newfilename;
> }
>
next prev parent reply other threads:[~2015-06-27 9:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-27 8:49 [RFC] perf tools: Add hugetlbfs memory recognition Hou Pengyang
2015-06-27 9:08 ` Hou Pengyang [this message]
2015-06-29 13:23 ` Arnaldo Carvalho de Melo
2015-06-29 13:42 ` Arnaldo Carvalho de Melo
2015-06-30 9:33 ` Hou Pengyang
2015-06-30 14:50 ` Arnaldo Carvalho de Melo
2015-07-03 10:21 ` Hou Pengyang
2015-07-03 15:16 ` 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=558E6804.5060602@huawei.com \
--to=houpengyang@huawei.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=wangnan0@huawei.com \
--cc=zhu.wen-jie@hp.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.