Messages in this thread | | | Date | Tue, 30 Jun 2015 11:50:49 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [RFC] perf tools: Add hugetlbfs memory recognition |
| |
Em Tue, Jun 30, 2015 at 05:33:05PM +0800, Hou Pengyang escreveu: > On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote: > >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: > >>>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: > > > > It seems no other info tell us if one process is using hugetlbfs. > So how about an option to tell perf explicitly which file is from > hugetlbfs, like: > > ./perf report --hugetlb-file=/mnt/huge/hugepagefile > > So that, we can check if a mmap area is from hugetlbfs by its name > instead of MAP_HUGETLB.
Well, we _can_ detect this automatically, its just a matter of parsing /proc/PID/smaps, right?
What I was discussing was a way only parse smaps when we know we need to, i.e. when we, for instance, parsing /proc/PID/maps, find a map that we think may be a hugetlb one, maybe some other way to tell us that hugetlb maps are in place, looking at the hugetlbfs stats somehow?
- Arnaldo
| |