> I think Rama and I are talking about something different from what
> Rik is talking about. Rather than using compression (only) to
> increase effective disk bandwidth, a fraction of RAM can be used
> to hold compressed pages, and avoid paging those out to disk and
> paging them back in again.
OK, I get your point on this one...
> If it is true that the dominant cost of paging is in seeks (and
> that seems likely) then a compressed page cache is a good idea;
> it's easy to compress and uncompress a page many times faster
> than a seek.
This sounds a bit like the philosophy behind WinModems
(the main processor is fast enough so why buy a DSP?).
While your idea is correct, you seem to be forgetting
the fact that disk transfers can be done in parallel
with useful CPU operations in other tasks.
Having to do (potentially a lot of, since you propose
losing 30% of useful memory) CPU costly compression
operations is definately not worth it on my system
(I/O and memory is in good balance with CPU and CPU is
usually a main bottleneck).
I agree it might be nice on those el-cheapo 300 MHz,
32 MB + EIDE Quantum Bigfoot garbage boxes, but I
really don't feel like optimizing the system to match
the insanity the people putting together that system
must have been in...
> Are there any plans to support hi-res time in the kernel? I think
> all the new processors have cycle timers, and that sort of thing
> is very handy for measuring the performance of system code.
Linux supports these things.
cheers,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/