lkml.org 
[lkml]   [2014]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/2] mm: free compound page with correct order
On Wed, Oct 15, 2014 at 12:30:44PM -0700, Andrew Morton wrote:
> On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao <yuzhao@google.com> wrote:
>
> > Compound page should be freed by put_page() or free_pages() with
> > correct order. Not doing so will cause tail pages leaked.
> >
> > The compound order can be obtained by compound_order() or use
> > HPAGE_PMD_ORDER in our case. Some people would argue the latter
> > is faster but I prefer the former which is more general.
> >
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
> > Cc: stable@vger.kernel.org (v3.8+)
>
> It's two years old and nobody noticed the memory leak, so presumably it
> happens rarely.
>
> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > ---
> > mm/huge_memory.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 74c78aa..780d12c 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -200,7 +200,7 @@ retry:
> > preempt_disable();
> > if (cmpxchg(&huge_zero_page, NULL, zero_page)) {
> > preempt_enable();
> > - __free_page(zero_page);
> > + __free_pages(zero_page, compound_order(zero_page));
>
> This is rare.
>
> > goto retry;
> > }
> >
> > @@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct shrinker *shrink,
> > if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) {
> > struct page *zero_page = xchg(&huge_zero_page, NULL);
> > BUG_ON(zero_page == NULL);
> > - __free_page(zero_page);
> > + __free_pages(zero_page, compound_order(zero_page));
>
> But I'm surprised that this is also rare. It makes me wonder if this
> code is working correctly.
>
> > return HPAGE_PMD_NR;
> > }
>
> Were you able to observe the leakage in practice? If so, under what
> circumstances?

Yes, not just on our servers (the worst case we saw is 11G leaked on
a 48G machine) but also on our workstations running Ubuntu based distro.

$ cat /proc/vmstat | grep thp_zero_page_alloc
thp_zero_page_alloc 55
thp_zero_page_alloc_failed 0

This means there is (thp_zero_page_alloc - 1) * (2M - 4K) memory leaked.


\
 
 \ /
  Last update: 2014-10-24 22:41    [W:0.072 / U:0.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site