summaryrefslogtreecommitdiff
path: root/mm/swap_state.c
diff options
context:
space:
mode:
authorNick Piggin <nickpiggin@yahoo.com.au>2005-05-01 08:58:37 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-05-01 08:58:37 -0700
commit20a77776c24800d1e40a73f520cfcb32239568a9 (patch)
tree8a28cc68cf10b87d35b7603b2d6f26215390cc0f /mm/swap_state.c
parentb84a35be0285229b0a8a5e2e04d79360c5b75562 (diff)
downloadlinux-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