[Bug corefiles/16981] New: "AnonHugePages:" is not checked with "Anonymous:"

[Bug corefiles/16981] New: "AnonHugePages:" is not checked with "Anonymous:"

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16981

            Bug ID: 16981
           Summary: "AnonHugePages:" is not checked with "Anonymous:"
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: corefiles
          Assignee: unassigned at sourceware dot org
          Reporter: jan.kratochvil at redhat dot com
        Depends on: 11804
            Target: *-linux-gnu

Created attachment 7615
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7615&action=edit
.c hugetlb attempt, not working for me

PR 11804 started to check "Anonymous:" but Linux kernel now also supports
"AnonHugePages:" and I think GDB should check also that /proc/PID/smaps entry.


Unfortunately during some experiments I am unable to get any hugetlb region, I
have tried qemu-kvm and also an attached .c attempt; This command has never
printed a line for me:
        grep -w ht /proc/*/smaps
Maybe my machines have too fragmented memory, I haven't tried some machine
after fresh reboot.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/16981] "AnonHugePages:" is not checked with "Anonymous:"

[sergiodj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16981

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergiodj at redhat dot com

--- Comment #1 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
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 <tools/testing/selftests/vm/hugepage-mmap.c>, inside the Linux kernel source
tree, to replicate this.  I also had to modify lots of settings...

First, according to
<https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt>, 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.