Re: 2.6.10-rc3: kswapd eats CPU on start of memory-eating task

[Nick Piggin <nickpiggin@yahoo.com.au>]

Nick Piggin wrote:
> Voluspa wrote:
> 
>> Earlier today I wrote:
>>
>>
>>> I find no problem when blender is the sole (large) application, but 
>>> when a
>>> distributed computing client is running in the background the reported 
>>
>>
>> problems
>>
>>> surface. I use http://folding.stanford.edu for protein folding. It runs
>>> with a default of nice 19 and sucks up every free CPU cycle. I've never
>>> seen it interfere with anything prior to this swap issue - been running
>>> it since 2000.
>>
>>
>>
>> More testing done to find the breaking point. Running the folding 
>> client and blender:
>>
>> 2.6.8.1-bk2 is the last kernel without _any_ swapping problem (no 
>> screen freezes etc)
>> |
>> | 2.6.9-rc1 and three -bk forward have oopses and loss of keyboard in 
>> X. Can't test them.
>> |
>> 2.6.9-rc1-bk4 is the first functional kernel where the freezes show up.
>>
>> So it is a real regression.
>>
> 
> Can you turn on magic sysrq in the kernel hacking menu, and press
> alt+sysrq+m a few times while kswapd is using lots of memory, please?
> 
> Then run `dmesg -s 1000000 > dmesg.out`, and send the dmesg over,
> please?
> 

By the way, I think the only relevant VM patches that went in between
2.6.8 and 2.6.9-rc2 are the following:

<nickpiggin@yahoo.com.au>
	[PATCH] vm: writeout watermark tuning

<nickpiggin@yahoo.com.au>
	[PATCH] vm: alloc_pages watermark fixes
	
<akpm@osdl.org>
	[PATCH] alloc_pages priority tuning

The first one shouldn't do much, and the last two should definitely
be improving things rather than anything else, because they cause
kswapd to properly start freeing in the background rather than force
the app to do the memory freeing itself.

This did expose a couple of bugs in kswapd, which were since fixed,
but are not in the 2.6.9-rc1-bk4 kernel.

So please, do the sysrq+m traces with a 2.6.10-rc3 kernel. Thanks.