RE:2.6.0-test4-mm1 - kswap hogs cpu OO takes ages to start!

RE:2.6.0-test4-mm1 - kswap hogs cpu OO takes ages to start!

[warudkar]

Con - With swappiness set to 100, the apps do start up in 3 minutes and kswapd doesn't hog the CPU. But X is still unusable till all of them have started up.
Wli - Sorry, vmstat segfaults on 2.6!

kernel@kolivas.org wrote
On Thu, 28 Aug 2003 07:38, warudkar@vsnl.net wrote:
> Trying out 2.6.0-test4-mm1. Inside KDE, I start OpenOffice.org, Rational
> Rose and Konsole at a time. All of these take extremely long time to
> startup. (approx > 5 minutes). Kswapd hogs the CPU all the time. X becomes
> unusable till all of them startup, although I can telnet and run top. Same
> thing run under 2.4.18 starts up in 3 minutes, X stays usable and kswapd
> never take more than 2% CPU.

Yes I can reproduce this with a memory heavy load as well on low memory 
(linking at the end of a big kernel compile is standard problem). I actually 
found the best workaround was to increase the swappiness instead of 
decreasing it.

Try 
echo 100 > /proc/sys/vm/swappiness

time it

then try
echo 0 > /proc/sys/vm/swappiness

you'll see that at low swappiness kswapd0 can use ridiculous amounts of cpu 
trying to avoid swap. The default is 60.

Con

Re: Re: 2.6.0-test4-mm1 - kswap hogs cpu OO takes ages to start!

[Parag Warudkar]

But eventually, kswapd does stop scanning and machine is back to normal after a 2 min freeze.
BTW, how is it cured at swappiness ==100?
> 
> 
> On Thu, 28 Aug 2003, Con Kolivas wrote:
> 
> > > Does this make a difference?
> > 
> > Tried it. No change. 
> > 
> > kswapd0 can hit 90% cpu at times unless the swappiness is increased.
> 
> Looks like the problem is that cache and process pages are on
> the same lists, forcing kswapd to scan the lists endlessly.
> 
> One thing you could try is splitting the lists, at least the
> active list, like done in 2.4-rmap15...
> 
> -- 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
>