On Tue, Dec 27, 2011 at 01:44:05PM +0900, KAMEZAWA Hiroyuki wrote: > To me, it seems kswapd does usual work...reclaim small memory until free > gets enough. And it seems 'dd' allocates its memory from ZONE_DMA32 because > of gfp_t fallbacks. > > > Memo. > > 1. why shrink_slab() should be called per zone, which is not zone aware. > Isn't it enough to call it per priority ? It is intended that it should be zone aware, but the current shrinkers only have global LRUs and hence cannot discriminate between objects from different zones easily. And if only a single node/zone is being scanned, then we still have to call shirnk_slab() to try to free objects in that zone/node, despite it's current global scope. I have some prototype patches that make the major slab caches and shrinkers zone/node aware - that is the eventual goal here - but first all the major slab cache LRUs need to be converted to be node aware first. Then we can pass a nodemask into shrink_slab() and down to the shrinkers so that those that have per-node LRUs can scan only the appropriate nodes for objects to free. This is someting that I'm working on in my spare time, but I have very little of that at the moment, unfortunately. > 2. what spinlock contention that perf showed ? > And if shrink_slab() doesn't consume cpu as trace shows, why perf > says shrink_slab() is heavy.. There isn't any spin lock contention - it's just showing how expensive locking superblocks is when it's being done every few microseconds for no good reason. > 3. because 8/9 of memory is in DMA32, calling shrink_slab() frequently > at scanning NORMAL seems to be time wasting. Especially as the shrink_slab() calls are returning zero pages freed every single time (i.e. the slab caches are empty). kswapd needs to back off here, I think, or free more memory at a time. Only freeing 100 pages at a time is pretty inefficient, esp. as we have 4 orders of magnitude more pages on the LRU and that is consuming >90% of RAM... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>