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

> iirc quicklists were just to avoid rezeroing pages which are known to
> be zero at free time (in theory __GFP_ZERO should handle that at
> page_alloc.c level, but it doesn't) and to get a little private fast path
> for the page allocator (might actually predate the current page_alloc
> fast paths)

Quicklists were introduced to increase performance of program termination
and startup. The avoidance of zeroing is one effect. The other reason that
made this a good optimization is the bad page allocator performance
in general vs a simple LIFO list.

The numbers that we saw on x86_64 were around a 90% reduction in overhead
with the quicklists.

The reason for the throttle is that termination and starting of large
programs would have to zero large amounts of memory and go through the
page allocator for all of this if the quicklists would be bounded to a
fixed limit. Having a fraction of free memory allows preserving large
amounts of page table pages for the next process that starts.

Right now quicklists do not make much sense because the x86_64 portion was
removed. IMHO The usefulness for i386 pgd/pud caching is negligible. The
code came initially from IA64 arch code (I think it was first on sparc64
though). After it became available in the core it was used by various other arches.

There have been a couple of people who wanted to continue work on
quicklists (which made me focus on different things) but so far nothing
has happened. Replacement of the i386 portion with alloc/free would be
fairly straightforward I would think.



\
 
 \ /
  Last update: 2008-03-10 16:55    [W:0.043 / U:1.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site