On Sun, 9 Mar 2008, Andi Kleen wrote:

quoted text
> 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.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/