On Thu, Apr 11, 2013 at 08:57:56PM +0100, Mel Gorman wrote: > If kswaps fails to make progress but continues to shrink slab then it'll > either discard all of slab or consume CPU uselessly scanning shrinkers. > This patch causes kswapd to only call the shrinkers once per priority. But the priority level changes _only_ when kswapd is not making progress, so I don't see how this fixes this case. On the other hand, what about shrinkable memory like dentries and inodes that build up during a streaming IO load like a backup program? Kswapd may be cooperating with the page allocator and never change priority as it reclaims the continuous file page stream, but it won't do the same for the stream of slab memory. So if anything, I would expect us to lay off slab memory when lru reclaim is struggling, but receive continuous aging and pushback as long as lru reclaim is comfortably running alongside the workload. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>