Re: [QUICKLIST 1/5] Quicklists for page table pages V3

[Christoph Lameter <clameter@sgi.com>]

On Mon, 19 Mar 2007, Andrew Morton wrote:

> Yes, a common quicklist implementation is good.  But no quicklist
> implementation at all is better.  You say that will be slower, and you may
> well be right, but I say let's demonstrate that (please) rather than
> speculating.

There are at least 3 arches already using this scheme there is no 
speculation here. The slab use in i386 is for exactly the same purpose. 
There is nothing new here. It consolidates code and fixes the page struct 
use conflict between slab and arch code. The conflict is the main reason 
why I want this. That way I will not have the special casing in SLUB and 
we can make SLAB support debugging for all slab caches.
 
> > Its obvious that this is right. And there has been significant work 
> > invested into retaining page table pages on i386, sparc64 and ia64 for 
> > exactly the specified.
> 
> I believe that work predated per-cpu-pages.

Lots of arch code depends on page table pages being in a known state for 
reuse this is nothing new. 

> > Ok great idea but what does this have to do with this patch? This patch 
> > simply generalizes something that has been there for ages.
> 
> It has a lot to do with this patch.
> 
> If we decide that it is useful to optimise the full-mm teardown case then
> we will need to zero these pages when we start to use them so we might as
> well get them straight from the page allocator.  Hence this patch goes into
> the bitbucket.

If you decide to optimise the full-mm teardown then you will have to 
rework more than half of the arch handling of page table pages since they 
all rely on pages being zero on return.

> It is not pie-in-the-sky to ask "is this code still useful?".

Yes it is if its a funky idea without code or any data to support a major 
change in the way we handle page table pages. And this falls into that 
category.