From: "M. Edward Borasky" <znmeb@aracnet.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: Which is better at vm, and why? 2.2 or 2.4
Date: Sat, 13 Oct 2001 11:06:16 -0700
Message-ID: <HBEHIIBBKKNOBLMPKCBBKEOIDOAA.znmeb@aracnet.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <E15sSOG-0003Fb-00@the-village.bc.nu>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Alan Cox
> Sent: Saturday, October 13, 2001 10:16 AM
> To: Patrick McFarland
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Which is better at vm, and why? 2.2 or 2.4
> > Now, the great kernel hacker, ac, said that 2.2 is better at vm
> in low memo=
> > ry situations than 2.4 is. Why is this? Why hasnt someone fixed
> the 2.4 cod=
> > e?
> Actually they have on thw whole. However VM tuning is a hard problem

Ah! Finally the t-word!! Yes, VM "tuning" is a hard problem. Because any
full-strength operating system, whether Windows NT, Linux, some other flavor
of UNIX or even MVS, can be used to support a variety of computational
endeavors, it is almost impossible to come up with a fixed "algorithm" that
will effectively support all legitimate usage patterns while protecting
users as much as possible from pathological usage patterns. Therefore ...

Most operating systems allow one to *measure* performance variables and give
system managers *control knobs* they can use to tune policy to a given
usage. For example, I once worked on a system where there were three modes.
During the day, the system was tuned for interactive users, on the swing
shift it was tuned to a mix of batch jobs and system administration
functions like backups, and on the graveyard shift it ran nothing but huge
batch jobs.

Linux certainly has the measurement capabilities; I've been able to find
everything I need in /proc for the monitoring and analysis I need to do. On
the control knobs, I think Linux falls short relative to, say, Solaris,
Tru64, VMS and Windows 2000. Nearly all decisions seem to be "hard-wired" in
Linux, for example, the goodness boosts given to processes to promote soft
affinity, the time slice, and the fractions of memory allocated to the
various functions: buffers, cached, etc. They are set as #defines in header
files. Even having them as variables would be an improvement; then they
could be examined and modified with a debugger.

I would like to be able to set up a test system in my laboratory, fire up a
benchmark that emulates a real-world workload and tweak these parameters
somewhere in /proc in real time, while watching the response times of my
benchmark transactions. I can do this in Tru64, I can do this in a number of
other operating systems. Right now, for all practical purposes, when I want
to perform an experiment like this, I need to recompile, quite often, the
*entire* kernel, reboot and re-run my benchmark. In other words, if the
parameters were tunable, what now takes *days* to do could be accomplished
in hours, even minutes, with just a little up-front work.
--
M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
http://www.borasky-research.net
mailto:znmeb@borasky-research.net
http://groups.yahoo.com/group/BoraskyResearchJournal

Q: How do you tell when a pineapple is ready to eat?
A: It picks up its knife and fork.

-
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/