Messages in this thread | | | Date | Thu, 3 Apr 2008 20:40:41 -0700 | From | "Nish Aravamudan" <> | Subject | Re: [BUG]:2.6.25-rc7 memory leak with hugepages. |
| |
On 3/27/08, Gurudas Pai <gurudas.pai@oracle.com> wrote: > > > Ingo Molnar wrote: > > * Gurudas Pai <gurudas.pai@oracle.com> wrote: > > > >> Hi, > >> > >> On 2.6.25-rc7 allocate hugepages and run a fio test with following > >> jobfile, > > > > could you try x86.git/latest: > > > > http://people.redhat.com/mingo/x86.git/README > > > > it has a fix that could fix such a leak. > > > > Ingo > > > Applied latest two patches and re-ran the test, > > hugetlb: fix potential livelock in return_unused_surplus_hugepages() > hugetlb: indicate surplus huge page counts in per-node meminfo > > Still same result,
Ingo was referring to the x86.git tree, not linus.git (to which those two patches have been applied). I'm not sure if there is something x86.git that hasn't been pushed to LInus yet?
> >cat /proc/meminfo | grep Huge > HugePages_Total: 1000 > > HugePages_Free: 551 > > HugePages_Rsvd: 1 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > > >echo 0 > /proc/sys/vm/nr_hugepages > >cat /proc/meminfo | grep Huge > > HugePages_Total: 450 > HugePages_Free: 1 > HugePages_Rsvd: 1 > HugePages_Surp: 450 > Hugepagesize: 2048 kB
Hrm, fio is using SHM_HUGETLB. Does ipcs indicate maybe fio is not cleaning up the shared memory segment? FWIW, it seems like each run is using 400 hugepages in the SHM_HUGETLB segment, and then when you try to force the pool to shrink, it converts those 800 (since you ran fio twice) hugepages from static pool pages to dynamic (or overcommit) pages.
On another note, it is odd that we're using the dynamic pool, when it is initially disabled...I'll have to think about that.
I'll try and look at this later this evening or early tomorrow.
Thanks, Nish
| |