Re: 2.4.8preX VM problems

[Daniel Phillips <phillips@bonn-fries.net>]

On August 11, 2001 02:06 pm, Pavel Machek wrote:
> > > I have come to the opinion that kswapd needs to be a little smarter
> > > -- if it doesn't find anything to swap shouldn't it go to sleep a
> > > little longer before trying again?  That way it could gracefully
> > > degrade itself when it's not making any progress.
> > >
> > > In my testing (on a dual 1Ghz/2G machine) the machine "locks up" for
> > > long periods of time while kswapd runs around trying to do it's
> > > thing. If I could disable kswapd I would just to test this.
> > 
> > Your wish is my command.  This patch provides a crude-but-effective 
> > method of disabling kswapd, using:
> > 
> >   echo 1 >/proc/sys/kernel/disable_kswapd
> > 
> > I tested this with dbench and found it runs about half as fast, but 
> > runs.  This is reassuring because kswapd is supposed to be doing 
> > something useful.
> 
> Why not just killall -STOP kswapd?

Because I didn't think of it and I wanted some code for myself to do 
real-time experimental tuning of the VM behaviour.

> What is expected state of system without kswapd, BTW? Without kflushd, 
> I give up guaranteed time to get data safely to disk [and its usefull
> for spindown]. What happens without kswapd?

Without kswapd you lose much of the system's 'clean-ahead' performance and it 
ends up reacting to try_to_free_pages calls iniated through __alloc_pages 
when processes run out of free pages.  This means lots more synchronous 
waiting on page_launder and friends, but the system still runs.  It's a nice 
way to check how well the system's attempt to anticipate demand is really 
working.

--
Daniel