Re: Kswapd in 3.2.0-rc5 is a CPU hog

[KOSAKI Motohiro]

(12/28/11 4:33 PM), Dave Chinner wrote:
> 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.

His machine only have one node. per node basis don't help him. We need
1) to make per zone LRU or 2) to implement more clever inter zone 
balancing code. but it seems off topic. I'm not sure why you are starting
talk about per node shrinker.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/