RE: Re: swap cache

Jason Chaw (jchaw@acm.org)
Mon, 21 Dec 1998 22:30:45 +0800


Today all workstations and servers have alot of memory, diskspace, bandwidth
(memory bus, disk I/O bus, etc). Hence the efficacy of compressed virtual
memory(VM) is no longer realised. As Rik pointed out, the main problem is
drive seeks. We should minimize on drive seeks. To merely compress the pages
of virtual memory is of little use. Disk reads / writes will not be
optimized.

For systems of low memory, The situation will be worse performance as the
limited memory resources will be further strained to accomodate the data
structures of the compression algorithm. Likewise for CPU resources.
The idea is to implement a VM which is optimized for swap in/out of the swap
partition. This will require simple and efficient algorithms.

We have to understand why we use VM. The system is running on borrowed time.

[JASON@CHAW]

----Original Message-----
>From: Paul R. Wilson [SMTP:wilson@cs.utexas.edu]
>To: linux-kernel@vger.rutgers.edu
>Cc: wilson@cs.utexas.edu
>Subject: Re: swap cache
>Type: IPM.Note
>Date: Monday, December 21, 1998 7:33 PM
>
>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.
>
>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.
>
>BTW, does anybody have suggestions for how to do precise timings
>inside or outside of the kernel? One of my students wrote some
>routines that read the Pentium-family instruction-cycle counter,
>so that we can time things down to a few nanoseconds. (This
>is how we measure the speed of our compression algorithms in
>userland.) If there are patches to do this in a better way, though,
>I'd be very interested. (Or if somebody wanted to use my student's
>code to implement hi-res time as a patch---maybe implementing
>Solaris-like gethrtime---Mark gives it away free.)
>
>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.
>
>
>-
>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/
>

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