I don't think so. A simple implementation could always avoid doing
compression if it's CPU-bound. Being able to compress stuff doesn't
force you to do it. A more sophisticated implementation would use
what idle time there is to do what compression is worthwhile, or
more generally would do the nearly-optimal thing---compressing
however much is worthwhile, given the workload.
My understanding is that most systems are either CPU-bound or
disk bound, or alternate between them. If your system is CPU
bound, it can easily avoid doing compression that wouldn't
improve throughput. If it's disk-bound, it can do compression
to reduce seeks. If it's alternating, it can do compression
when it's disk bound, putting the CPU to good use, and not
do it when it's CPU bound.
>This whole thread is domitated by "one process at a time" thinking.
Not on my part. I'm making several different claims about compressed
caching, which I should have been careful to distinguish (sorry):
1. for small diskless systems, it's a win
2. for small systems with slow disks, or where
power consumption is an issue, it's a win
3. for I/O bound systems, it's a win,
4. for CPU-bound systems, it can turn itself off and avoid
being a lose
5. for systems that are CPU-bound sometimes and disk-bound
sometimes, it can adapt and do the right thing in each
case
6. CPU speeds (and compression algorithm speeds) are now fast
enough that it's usually a win
7. As CPUs get faster relative to disks, it'll tend toward
being a bigger win, and almost always being a win
The two key underlying ideas are the changing tradeoffs due to
technology trends, and the ability to adapt. A compression cache
is a different beast from any other level of the memory hierarchy,
because you can dynamically change the size of the cache and favor
more fast memory (plain RAM) vs. much more slower memory (compressed
RAM). If done right, there's not much to lose, and a lot to gain.
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
-
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/