Re: how not to write a search algorithm

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

William Lee Irwin III wrote:
> 
> On Sun, Aug 04, 2002 at 03:43:56PM -0700, Andrew Morton wrote:
> > Getting the kernel back to the level of performance and stability
> > which it had before the rmap patch has to be the first step.
> > 1) 50% increase in system load on fork/exec/exit workloads
> > 2) Will oops on pte_chain oom
> > 3) pte_highmem is bust
> > 4) tripled ZONE_NORMAL consumption
> > 5) pte chains go wrong with ntpd
> > The first three or four here are fatal to the retention of the
> > reverse map, IMO.  Futzing around fixing them is taking time
> > and is holding up other work.
> > I may have a handle on 1).  Still working it.
> 
> (2) only needs the reservation bits from the preceding post if it's
>         just dealing with kmem_cache_alloc() returning NULL.

Well I think we'll need a per-cpu-pages thing to amortise zone->lock
contention anyway.  So what we can do is:

	fill_up_the_per_cpu_buffer(GFP_KERNEL);		/* disables preemption */
	spin_lock(lock);
	allocate(GFP_ATOMIC);
	spin_unlock(lock);
	preempt_enable();

We also prevent interrupt-time allocations from
stealing the final four pages from the per-cpu buffer.

The allocation is guaranteed to succeed, yes?   Can use
it for ratnodes as well.
--
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/