Re: [3.13 regression] kswapd0 and ksoftirqd/0 CPU hogs

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Finn,
> On Tue, 7 Apr 2015, Michael Schmitz wrote:
>
>   
>> The gunzip error cannot be reproduced on any of my ARAnyM VMs. Might be 
>> a RAM error or other hardware related problem. Same kernel but 
>> configured slightly different (added 030 and 040 support, plus ARAnyM 
>> support).
>>     
>
> The configuration differences could be cancelled by booting your new 
> aranym kernel on the physical hardware, and reproducing the fault that 
>   

Sure, and I'll make certain to do that once I've finished the current 
task (updating stuff in a current unstable chroot).

> way. BTW, is this the same physical machine that has DMA issues, which we 
> discussed off-list in the past?
>   

The very same. Runs fairly stable otherwise though - I would have 
expected filesystem corruption or other more drastic errors if the RAM 
was faulty.

>   
>> The general behaviour (gunzip eats up all free RAM, then kswapd spins 
>> doing nothing very apparent, with no dirty pages to be flushed and 
>> cached pages never released) remains the same. Though I've seen the 
>> gunzip complete without kicking off kswapd on occasion (had set 
>> dirty_background_ratio and dirty_ratio half the default for that).
>>
>> And yes, dropping cached pages as Andreas suggested, does free up 
>> significant (i.e. most of all) RAM and shuts up kswapd.
>>     
>
> This bug has been reported to Red Hat in the past (on x86_64). They closed 
> the bugzilla entry in 2011, but the bug was still being reported by Fedora 
> users in 2014. https://bugzilla.redhat.com/show_bug.cgi?id=712019
>   

Thanks for pointing that out!

The patches attached to this report made it into Linus' git tree at that 
time so I presume we are seeing something closely related. The 
discussion on LRML makes my head spin - not a chance to debug this in a 
meaningful way, I suppose.

    Michael