Re: how not to write a search algorithm

[Andrew Morton <akpm@zip.com.au>]

Daniel Phillips wrote:
> 
> On Sunday 04 August 2002 23:09, Andrew Morton wrote:
> > Seems that simply changing the page_add_ramp() interface to require the
> > caller to pass in one (err, two) pte_chains would suffice.  The tricky
> > one is copy_page_range(), which is probably where -ac panics.
> 
> Hmm, seems to me my recent patch did exactly that.  Somebody called
> it 'ugly' ;-)
> 
> I did intend to move the initialization of that little pool outside
> copy_page_range, and never free the remainder.
> 
> Why two pte_chains, by the way?

Converting from a PageDirect representation to a shared-by-two
representation needs two pte_chains.

> > I suppose we could hang the pool of pte_chains off task_struct
> > and have a little "precharge the pte_chains" function.  Gack.
> 
> It's not that bad.  It's much nicer than hanging onto the rmap lock
> while kmem_cache_alloc does its thing.

The list walk is killing us now.   I think we need:

struct pte_chain {
	struct pte_chain *next;
	pte_t *ptes[L1_CACHE_BYTES/4 - 4];
};

Still poking...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/