Re: kswapd0: excessive CPU usage

From: Zdenek Kabelac
Date: Mon Nov 12 2012 - 09:50:45 EST


Dne 12.11.2012 14:31, Mel Gorman napsal(a):
On Mon, Nov 12, 2012 at 02:13:20PM +0100, Zdenek Kabelac wrote:
Dne 12.11.2012 13:19, Mel Gorman napsal(a):
On Sun, Nov 11, 2012 at 10:13:14AM +0100, Zdenek Kabelac wrote:
Hmm, so it's just took longer to hit the problem and observe kswapd0
spinning on my CPU again - it's not as endless like before - but
still it easily eats minutes - it helps to turn off Firefox or TB
(memory hungry apps) so kswapd0 stops soon - and restart those apps
again.
(And I still have like >1GB of cached memory)


I posted a "safe" patch that I believe explains why you are seeing what
you are seeing. It does mean that there will still be some stalls due to
THP because kswapd is not helping and it's avoiding the problem rather
than trying to deal with it.

Hence, I'm also going to post this patch even though I have not tested
it myself. If you find it fixes the problem then it would be a
preferable patch to the revert. It still is the case that the
balance_pgdat() logic is in sort need of a rethink as it's pretty
twisted right now.



Should I apply them all together for 3.7-rc5 ?

1) https://lkml.org/lkml/2012/11/5/308
2) https://lkml.org/lkml/2012/11/12/113
3) https://lkml.org/lkml/2012/11/12/151


Not all together. Test either 1+2 or 1+3. 1+2 is the safer choice but
does nothing about THP stalls. 1+3 is a riskier version but depends on
me being correct on what the root cause of the problem you see it.

If both 1+2 and 1+3 work for you, I'd choose 1+3 for merging. If you only
have the time to test one combination then it would be preferred that you
test the safe option of 1+2.



I'll go with 1+2 for couple days - the issue is - I've no idea how it gets
suddenly triggered - it seemed to be running fine for 2-3 days even with
just 1) - but then kswapd0 started to occupy CPU for minutes.
Looks like some intensive workload on firefox (flash) may lead to that.

Anyway it's hard to tell quickly if it helped.

Zdenek

--
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/