Messages in this thread |  | | Date | Sat, 13 Oct 2001 14:17:09 -0400 | From | Patrick McFarland <> | Subject | Re: Which is better at vm, and why? 2.2 or 2.4 |
| |
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 [unhandled content-type:application/pgp-signature] |  |