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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Apr 2008 20:40:41 -0700
From:	"Nish Aravamudan" <nish.aravamudan@...il.com>
To:	"Gurudas Pai" <gurudas.pai@...cle.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [BUG]:2.6.25-rc7 memory leak with hugepages.

On 3/27/08, Gurudas Pai <gurudas.pai@...cle.com> wrote:
>
>
>  Ingo Molnar wrote:
>  > * Gurudas Pai <gurudas.pai@...cle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/