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. Thanks. -- Mel Gorman SUSE Labs -- 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>