Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: 2.4.8preX VM problems | Date | Thu, 16 Aug 2001 23:57:49 +0200 |
| |
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/
| |