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