Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Arnaldo Carvalho de Melo]

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:
> > 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.
> 
> Humm:
> 
> [root@zoo ~]# wc -l /proc/`pidof firefox`/maps
> 934 /proc/4551/maps
> [root@zoo ~]# wc -l /proc/`pidof firefox`/smaps
> 14944 /proc/4551/smaps
> [root@zoo ~]#
>  
> > 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?
> 
> Doing some research now...

Bummer, seems that only smaps -> ... -> show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:

[root@zoo ~]# find /proc -name smaps | xargs grep -w ht
grep: /proc/31971/task/31971/smaps: No such file or directory
grep: /proc/31971/smaps: No such file or directory
[root@zoo ~]#

No "ht" HugeTLB areas, so no need to parse 16 times more bytes than by
just using /proc/PID/maps.

- Arnaldo
--
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/