Re: Which is better at vm, and why? 2.2 or 2.4

[Patrick McFarland <unknown@panax.com>]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

Hmm, I see that as very bad. There should be a bunch of sysctls to do that easily. Also, I heard that 2.4 (and I'm assuming 2.2 as well) swaps pages on a last-used-age basis, instead of either a number-of-times-used or a hybrid of the two. That kinda seems stupid, especially if you get a bunch of apps running that just cycle thru pages, instead of the most used pages staying in memory, and the least used being swapped back and forth with about 2 or 3 megs of memory used to store the least used pages in memory

On 13-Oct-2001, M. Edward Borasky wrote:
> > -----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/
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]