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