lkml.org 
[lkml]   [2008]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: quicklists confuse meminfo
On Sun, 9 Mar 2008, Ingo Molnar wrote:

>
> * Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > Bart reported http://bugzilla.kernel.org/show_bug.cgi?id=9991. He
> > assumed a memory leak in 32bit kernels when he analyzed the output of
> > /proc/meminfo.
> >
> > The leak is not a leak, it's an accounting bug. quicklists keep a
> > large amount of pages which are accounted as used memory.
> [...]
> > Another strange observation about quicklists is the imbalance of the
> > quicklists across CPUs. Running the above loop on a 2way machine I can
> > observe that the quicklist pages are acuumulating on one CPU. Stopping
> > and restarting the loop a couple of times can shift the accumulation
> > from one to the other CPU.
>
> hm. I think we should not let this much RAM hang around in a
> special-purpose allocator like quicklists. Shouldnt the quicklists be
> temporary in nature, and be trimmed much more agressively?
>
> in fact, we have a check_pgt_cache() call in cpu_idle(), which does:
>
> quicklist_trim(0, pgd_dtor, 25, 16);
>
> but it appears we dont do quicklist trimming anywhere else! So if a
> system has no idle time, the quicklist can grow unbounded, and that's a
> real memory leak IMO.

Right, also the quicklist_trim() in idle() is freeing at max 16 pages
in one go. According to the quicklist_trim() code we keep up to
(node_free_pages / 16) in the quicklist unconditionally, which seems
rather odd as well.

Thanks,
tglx


\
 
 \ /
  Last update: 2008-03-09 12:59    [W:0.094 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site