Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 19 Jan 1999 21:35:33 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: VM20 behavior on a 486DX/66Mhz with 16mb of RAM |
| |
This written by Stephen:
> > Horrible --- smells like the old problem of "oh, our VM is hopeless at > > tuning performance itself, so let's rely on magic numbers to constrain > > it to reasonable performance". I'd much much much much rather see a VM
My point is that the algorithm to do something of useful and safe needs an objective to reach. The algorithm need to know what has to do. I learn to the algorithm what to do, nothing more.
Swapping out when shrink_mmap fails, means nothing. You don't know what will happens to the memory levels. This is the reason it works worse than my way (and that slowdown machines after some day).
And btw, I don't care `work with magic'. I care that everything works efficient, stable, and confortable. 1 only level of cache percentage tunable looks fine to me (everything else works with magic and works fine, but I need at least 1 fixed point to learn at the algorithm what to do). You can write a gtk app that allow the sysadm to move up and down the _only_ cache percentage level. I dropped all others bogus percentage levels. So at least my code is 6/1 times less Horrible than pre8 (and sctvm) from your `must work (and mess) with magic' point of view.
If I am missing something (again ;) comments are always welcome.
Andrea Arcangeli
- 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/
| ![\](/images/icornerr.gif) |