On Friday 23 November 2001 6:30 am, Charles Marslett wrote:
> 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.
That wasn't quite what I had in mind :)
> 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).
Yes, sometimes you'll get better behaviour in a specific case by "disabling"
swap (i.e. forcing the kernel to page code instead), which in other cases
causes nasty disk thrashing. In this case, though, I think the VM could do a
much better job than it does presently; I've a feeling Rik's would perform
better in this case, for example...
> 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.
Nobody said VM coding was easy - or that Microsoft had got it right :)
James.
-
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