From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8739 invoked by alias); 1 Jun 2014 05:00:41 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 8707 invoked by uid 48); 1 Jun 2014 05:00:36 -0000 From: "sergiodj at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug corefiles/16981] "AnonHugePages:" is not checked with "Anonymous:" Date: Sun, 01 Jun 2014 05:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: corefiles X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sergiodj at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q2/txt/msg00355.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16981 Sergio Durigan Junior changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sergiodj at redhat dot com --- Comment #1 from Sergio Durigan Junior --- Size: 8192 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 2048 kB MMUPageSize: 2048 kB Locked: 0 kB VmFlags: rd wr sh mr mw me ms de ht sd I managed to produce the "ht" there. This whole part of memory management is very confusing. I am using the program on , inside the Linux kernel source tree, to replicate this. I also had to modify lots of settings... First, according to , one has to check the value of "HugePages_Total:" on /proc/meminfo. In my machine, it was 0, which meant that HugeTLB was never really used. So the first thing I had to do was to actually increase this number; I have chosen 20 as a guess (based on the documentation's example): echo 20 > /proc/sys/vm/nr_hugepages Then, in order to use the .c example mentioned above, I had to mount a hugetlbfs filesystem: mount -t hugetlbfs nodev /home/sergio/mnt And also give proper permissions to my user: chown sergio:sergio /home/sergio/mnt -R Now, I modified the .c file in order to mmap a file inside this directory. But only doing that did not prove enough: $ ./a.out mmap: Cannot allocate memory So, by checking the output of /proc/meminfo again, I saw: Hugepagesize: 2048 kB Since I had added 20 huge pages to the poll, I modified the .c file to mmap only 8 MB of huge pages (I could have used more memory). And only then I was finally able to see the "ht" there. IMO, all of this investigation ultimately means that we could probably check for "hg" instead of "ht" in the VmFlags. -- You are receiving this mail because: You are on the CC list for the bug.