[lkml]   [2001]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Swap vs No Swap.
James A Sutherland wrote:
> On Thursday 22 November 2001 4:00 pm, war wrote:
> > Incorrect, my point is I have enough ram where I am not going to run out
> > for the things I do.
> There's more to it than "not run out". You have some fixed amount of RAM; if
> the VM is working properly, adding swap will IMPROVE performance, because
> that fixed amount of RAM is used more efficiently.
> Obviously, there are cases where removing swap breaks the system entirely,
> but even in other cases, adding swap should *never* degrade performance. (In
> theory, anyway; in practice, it still needs tuning...)
> > Using swap simply slows the system down!
> In which case, the VM isn't working properly; it SHOULD page out infrequently
> used data to make more room for caching frequently used files.
> James.

I disagree. It is true that a VM could be designed sufficiently complex that
it would properly analyze every possible sequence of execution and have perfect
prescience. It would probably take a few hundred gigabytes of table structure
to do that and that in itself will slow down the VM just scanning those tables,
I dare say.

In short, no VM is going to work perfectly -- it is extrapolating a model of
behavior to a real world sequence of events and as such there will always be
some real world set of programs and events that will make it worse than some
other model of behavior (VM), including the one that never pages at all. We
just want that to happen rarely (whatever that means).

A VM that is working properly is one that satisfies the beholder (sort of like
beauty). And in fact, if you look at the various similar discussions on
Microsoft newsgroups (sorry ;-), you may notice they don't seem to be able
to come up with a mechanism that handles large uniform access working sets
and still works well with "normal" (highly peaked) working sets. So I doubt
it is an easy problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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