Then it sounds like the current algorithm is totally broken and needs
replacement. If it's impossible to make a system stable by choosing the
right numbers, the system needs changing, not the numbers. I think that's
pretty much what we're being taught in Control Engineering. :)
Not having studied the code too closely, it sounds as though there are half
a dozen different "clocks" running for different types of memory, and each
one runs at a different speed and is updated at a different time.
Meanwhile, the paging-out is done on the assumption that all the clocks are
(at least roughly) in sync. Makes sense, right? (not!)
I think it's worthwhile to think of the page/buffer caches as having a
working set of their own - if they are being heavily used, they should get
more memory than if they are only lightly used. The important point to get
right is to ensure that the "clocks" used for each memory area remain in
sync - they don't have to measure real time, just be consistent and fine
granularity.
I'm working on some relatively small changes to vmscan.c which should help
improve the behaviour without upsetting the balance too much. Watch this
space...
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@cyberspace.org (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
-
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/