Re: [BUG]:2.6.25-rc7 memory leak with hugepages.

["Nish Aravamudan" <nish.aravamudan@gmail.com>]

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