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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:18 EST