Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752732AbbF3JeN (ORCPT ); Tue, 30 Jun 2015 05:34:13 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:8839 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643AbbF3JeF (ORCPT ); Tue, 30 Jun 2015 05:34:05 -0400 Message-ID: <55926251.9000404@huawei.com> Date: Tue, 30 Jun 2015 17:33:05 +0800 From: Hou Pengyang User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: , , , , , Subject: Re: [RFC] perf tools: Add hugetlbfs memory recognition References: <1435394953-146405-1-git-send-email-houpengyang@huawei.com> <558E6804.5060602@huawei.com> <20150629132329.GC11747@kernel.org> <20150629134234.GD11747@kernel.org> In-Reply-To: <20150629134234.GD11747@kernel.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.95.59] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2752 Lines: 80 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: >>> 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: > 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. > [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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/