diff options
author | akpm@osdl.org <akpm@osdl.org> | 2005-06-21 17:14:35 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-06-21 18:46:13 -0700 |
commit | b15e0905f2b9964fc7426fecab57445e96021b61 (patch) | |
tree | bc1b3606cf282f88cd6598de22190eff6708affa /mm/madvise.c | |
parent | 39c715b71740c4a78ba4769fb54826929bac03cb (diff) | |
download | linux-3.10-b15e0905f2b9964fc7426fecab57445e96021b61.tar.gz linux-3.10-b15e0905f2b9964fc7426fecab57445e96021b61.tar.bz2 linux-3.10-b15e0905f2b9964fc7426fecab57445e96021b61.zip |
[PATCH] vmscan: notice slab shrinking
Fix a problem identified by Andrea Arcangeli <andrea@suse.de>
kswapd will set a zone into all_unreclaimable state if it sees that we're not
successfully reclaiming LRU pages. But that fails to notice that we're
successfully reclaiming slab obects, so we can set all_unreclaimable too soon.
So change shrink_slab() to return a success indication if it actually
reclaimed some objects, and don't assume that the zone is all_unreclaimable if
that is true. This means that we won't enter all_unreclaimable state if we
are successfully freeing slab objects but we're not yet actually freeing slab
pages, due to internal fragmentation.
(hm, this has a shortcoming. We could be successfully freeing ZONE_NORMAL
slab objects while being really oom on ZONE_DMA. If that happens then kswapd
might burn a lot of CPU. But given that there might be some slab objects in
ZONE_DMA, perhaps that is appropriate.)
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'mm/madvise.c')
0 files changed, 0 insertions, 0 deletions