diff options
author | Nick Piggin <nickpiggin@yahoo.com.au> | 2005-05-01 08:58:37 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-05-01 08:58:37 -0700 |
commit | 20a77776c24800d1e40a73f520cfcb32239568a9 (patch) | |
tree | 8a28cc68cf10b87d35b7603b2d6f26215390cc0f /mm/swap_state.c | |
parent | b84a35be0285229b0a8a5e2e04d79360c5b75562 (diff) | |
download | linux-3.10-20a77776c24800d1e40a73f520cfcb32239568a9.tar.gz linux-3.10-20a77776c24800d1e40a73f520cfcb32239568a9.tar.bz2 linux-3.10-20a77776c24800d1e40a73f520cfcb32239568a9.zip |
[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>
Diffstat (limited to 'mm/swap_state.c')
0 files changed, 0 insertions, 0 deletions