Re: Swap vs No Swap.

From: Charles Marslett (cmarslett9@cs.com)
Date: Fri Nov 23 2001 - 01:30:10 EST


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.

--Charles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:32 EST