>
> maybe more specific: If the hit-rate is low and the cache is already
> 70+% of the systems memory, the chances maybe slim that more cache is
> going to improve the hit-rate.
>
Oh, but this is posible. You can get into situations where
the (file cache) working set needs 80% or so of memory
to get a near-perfect hitrate, and where
using 70% of memory will trash madly due to the file access
pattern. And this won't be a problem either, if
the working set of "other" (non-file)
stuff is below 20% of memory. The total size of
non-file stuff may be above 20% though, so something goes
into swap.
I definitely want the machine to work under such circumstances,
so an arbitrary limit of 70% won't work.
Preventing swap-trashing at all cost doesn't help if the
machine loose to io-trashing instead. Performance will be
just as much down, although perhaps more satisfying because
people aren't that surprised if explicit file operations
take a long time. They hate it when moving the mouse
or something cause a disk access even if their
apps runs faster. :-(
Helge Hafting
-
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/