lkml.org 
[lkml]   [1998]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Swap Cache
> From: "Paul R. Wilson" <wilson@cs.utexas.edu>
> Date: Mon, 21 Dec 1998 17:28:11 -0600
> Subject: Re: Swap Cache
>
> >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.
>
> I do realize that it's an issue. I just don't believe
> it's fatal. For many workloads, a system is either CPU bound
> or I/O bound, and you can easily tell which. And as CPU's
> get faster and memory gets larger, the tradeoffs get less
> tense.

i think that paging and CPU operations only happen at the same
time on a system that has many things to do. in most cases the
CPU must wait for page operations to complete anyway. but that
point has probably already been made.

> I have a bit of a feeling that compressed caching is being
> criticized on shifting grounds. If RAM is cheap, then
> buy a little extra and use compression to double it, so
> that you never page. If RAM is expensive, and you're
> I/O bound, then you clearly need it. Take your pick.

seems to me putting more than 4G into an Intel PC is
"infinitely expensive" -- for anything other than a Xeon
CPU, you can't do it. does anyone think that using page
compression might help ease this constraint? what if this
were a way to effectively use more than 4G by, say, making
the "high memory" area a swap staging area?

in other words, this type of effort may have more wide use
than just as a way to make a poor student's machine more
cost effective.

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

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.027 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site