Messages in this thread | | | Date | Sat, 5 Dec 1998 20:20:15 +0100 (CET) | From | Rik van Riel <> | Subject | Re: memory management |
| |
On Sat, 5 Dec 1998, David Feuer wrote:
> It seems from what I've seen on this list that there may not be one > (finitely described) set of memory management algorithms that are > optimal for all systems.
It appears that I have a good enough approximation in my tree right now. Only the swapin readahead needs to be tuned in order to reflect the actual needs of the process we're doing readahead for...
> I think it might be a good idea to provide several separate > algorithms, each optimized for certain amounts of physical RAM and > certain system conditions (e.g. lots of little processes vs. a few > big ones, lots of CPU-intensive processes vs. mostly disk-bound, > huge hard-drive vs. embedded system.....).
With the new VM scheme (introduced in 2.1.130) this is all built in and only needs some fine tuning. Stephen's change to filemap.c and my (small) changes to vmscan.c and some other files (not in Linus' tree yet! Get them from my home page) have evened out all that's needed to be done for 'normal' workloads.
The case of a few huge (and swapping) processes is effectively tackled by means of swapin readahead and the case of lots of CPU intensive task is not a VM problem at all -- it can be solved at the scheduler level.
<plug>Fixes for these three problems can be downloaded from my home page.</plug>
> The memory management could be selected by > (in increasing order of flexibility and decreasing order > of ease of implementation)
The most realistic option for done-by-hand VM tuning is through /proc/sys/vm/*. In 2.3 (it's too late for 2.2) I will provide switches where people can switch entire algorithms (eg. swapin readahead) on and off.
Numeric tuning should dissapear as much as possible. The kernel should be able to tune stuff like that all by itself (ie. it shouldn't depend on the user to patch things up).
Of course, we can keep the all tunable stuff if we want, it doesn't really cost us anything in performance or whatever (maybe 500 bytes sysctl data, but that's it) and people could possibly want to amuse themselves by frobbing with the values :)
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |