commit 20a77776c24800d1e40a73f520cfcb32239568a9
author Nick Piggin <nickpiggin@yahoo.com.au> Sun May 01 08:58:37 2005 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> Sun May 01 08:58:37 2005 -0700
tree 8a28cc68cf10b87d35b7603b2d6f26215390cc0f
parent b84a35be0285229b0a8a5e2e04d79360c5b75562

[PATCH] mempool: simplify alloc

Mempool is pretty clever.  Looks too clever for its own good :) It
shouldn't really know so much about page reclaim internals.

- don't guess about what effective page reclaim might involve.

- don't randomly flush out all dirty data if some unlikely thing
  happens (alloc returns NULL). page reclaim can (sort of :P) handle
  it.

I think the main motivation is trying to avoid pool->lock at all costs.
However the first allocation is attempted with __GFP_WAIT cleared, so it
will be 'can_try_harder' if it hits the page allocator.  So if allocation
still fails, then we can probably afford to hit the pool->lock - and what's
the alternative?  Try page reclaim and hit zone->lru_lock?

A nice upshot is that we don't need to do any fancy memory barriers or do
(intentionally) racy access to pool-> fields outside the lock.

Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>