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

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Mikael,
>  > has anyone found a solution to this one?
>  > 
>  > 3.18-rc5 has kswapd0 hogging the CPU - haven't seen ksoftirqd0 yet.
>  > Unpacking a large tarball tends to trigger this for me.
>
> Alas, no.  I went back to the 3.10.xx kernels and they work Ok for me
> (they tend to hang during shutdown, but I can live with that).
>   

I've followed the vm stats while running gunzip -c on a large file. I 
get an 'invalid compressed data' error at the very end of the gunzip 
run, and the file md5sum does not match what I get when uncompressing 
that file on another system with no error

As long as that file will fit into available memory, all that happens is 
kswapd0 and/or kswapd1 running forever after gunzip has finished. kswapd 
running full tilt appears to coincide with the number of free pages 
hitting the min_free_kbytes limit. The number of dirty pages never grows 
very large (hovers around 1000, less than 1% of RAM size) and remains 
below the nr_dirty_threshold (10800) and nr_dirty_background_threshold 
(5400) limits at all time. (Both limits progressively shrink over time - 
is that normal?).

If I force the VM to only use part of the RAM (by setting 
min_free_kbytes to say 10% of RAM size), the system becomes unresponsive 
as soon as the limit is reached. The swap tasks start to eat substantial 
amounts of CPU once the number of free pages approaches  that limit , 
nr_dirty drops at that time, and nr_dirty_threshold as well as 
nr_dirty_background_threshold begin to rise again  - above the initial 
values, in fact.
> I should do a git bisect...
>   

Would be nice to be able to force this a lot quicker. I'll try with 
smaller files to uncompress, and larger min_free limit.

Cheers,

    Michael

> /Mikael
>
>  > 
>  > Cheers,
>  > 
>  >   Michael
>  > 
>  > 
>  > On Tue, Jul 1, 2014 at 11:43 PM, Mikael Pettersson <mikpelinux@gmail.com> wrote:
>  > > Andreas Schwab writes:
>  > >  > Mikael Pettersson <mikpelinux@gmail.com> writes:
>  > >  >
>  > >  > > Reverting to 3.12.16 completely eliminates these problems.
>  > >  >
>  > >  > Even 3.11 has the kswapd0 cpu hog problem.
>  > >
>  > > Hmm, I just got the kswapd0 CPU hog on 3.12.16 too (while compiling
>  > > java code during a gcc package rebuild).
>  > >
>  > > So kernels >= 3.11 have the kswapd0 CPU hog bug, and kernels >= 3.13
>  > > also have the ksoftirdq/0 CPU hog bug.
>  > >
>  > > What's the last known-good kernel? 3.10?
>  > > --
>  > > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>  > > the body of a message to majordomo@vger.kernel.org
>  > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>