From: safemode <safemode@speakeasy.net>
To: linux-kernel@vger.kernel.org
Subject: Re: VM
Date: Tue, 16 Oct 2001 01:08:02 -0400 [thread overview]
Message-ID: <20011016050739Z278091-17409+653@vger.kernel.org> (raw)
In-Reply-To: <20011015211216.A1314@localhost> <20011015232245.F1314@localhost> <1003202891.863.1.camel@phantasy>
In-Reply-To: <1003202891.863.1.camel@phantasy>
I think it was said earlier that we're dealing with definitions of stability
and performance.
If you look at stability as being able to depend on an effect given a cause,
then andrea's has been said to be more stable in that sense. If you look at
performance being the amount of different situations that the vm is stable
and everything else being a lower priority, then andrea's vm is better
performing.
Rik's vm is performance first, meaning it tries to do what's best for each
situation and basically the difference is that rik's vm has more variables
effecting what happens. This treats everything differently but it means that
each situation is dealt with personally instead of trying to blanket each
like situation. That basically destroys our previous definition of
stability. So we make a new one. Stability here deals with how much the
system needs to stop other things for VM things. Of course the not
corrupting things and crashing things are implied to both definitions.
For instance though, when you swap, that takes time away to write to disk.
This can take longer than a complex way of re-arranging pages and removing
pages in ram.
It seems like andrea's vm is more tuned for systems that do the same things
over and over, like a server. And rik's vm is more tuned for systems that
you dont know what is going to be run or is running numerous programs that
have no real regularity.
And complex does not mean smart, but it doesn't mean it can't be smart. When
you're dealing with something as complex as a VM, using a simplistic approach
may just be too limiting in the end and I think many people are seeing that
when they say programs are more responsive in alan's kernel and memory usage
is more efficient. It doesn't seem very logical to make the VM do B when you
do A on a multiprocessing system unless the environment is exactly the same
every time you do A because what's good at one time doesn't mean it's good
the second or third time you do it either due to memory limitations or other
applications requiring different things of the VM.
I'm kind of picturing the two VM's like the two parts of our brain. The
brain stem (sometimes called the reptillian brain) and the cerebrum. Your
reptillian brain is quite fast at reacting and can make a few decisions on
what to do based on a few specific variables. The cerebrum is slower at
those same tasks but it better manages those tasks, based on many more
variables, so that the reaction is not too much or too little so that the
next thing that happens is in a better position than what the reptillian
brain would have left for it.
Of course being able to do more means you have opened yourself up to more
problems. I wont speak for all ac branch users, but i feel that the more
complex way of handing memory is a better choice because it's a function of
the kernel that demands a complex solution. A simplistic solution is too
limited, it would be like reacting from your brain stem and overreacting
instead of using your higher logic and taking a more educated reaction.
And that's all the contraversy, deciding if 2.4's VM demands a complex
solution that handles each situation uniquely, or it can have a simple
solution that handles a wide range fairly good.
Perhaps aiming for a simplistic VM should be the goal of 2.5 from the
beginning ( as if it wasn't), that way you can build everything else around
it and avoid all this vm trouble that 2.4 has been plagued with since the mid
2.3 days.
next prev parent reply other threads:[~2001-10-16 5:07 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20011015232245.F1314@localhost>
2001-10-16 1:12 ` VM Patrick McFarland
2001-10-16 0:53 ` VM David Lang
2001-10-16 12:28 ` VM John Levon
2001-10-16 12:34 ` VM Tobias Ringstrom
2001-10-16 16:17 ` VM David Lang
2001-10-16 1:57 ` VM Linus Torvalds
2001-10-16 3:08 ` VM Patrick McFarland
2001-10-16 3:15 ` VM Patrick McFarland
2001-10-16 23:24 ` VM Andrea Arcangeli
2001-10-16 3:15 ` VM Robert Love
2001-10-16 3:17 ` VM Patrick McFarland
[not found] ` <1003202417.861.6.camel@phantasy>
2001-10-16 3:28 ` VM Robert Love
2001-10-16 5:08 ` safemode [this message]
2001-10-16 4:40 ` VM David Lang
2001-10-16 13:34 ` VM safemode
2001-10-16 14:19 ` VM Allan Sandfeld
2001-10-16 16:14 ` VM Rik van Riel
2001-10-16 8:14 ` VM Anuradha Ratnaweera
2001-10-16 13:36 ` VM Luigi Genoni
2001-10-16 14:04 ` VM bill davidsen
2001-10-16 14:11 ` VM Rik van Riel
2001-10-16 14:41 ` VM Martin Dalecki
2001-10-16 10:26 ` VM Stephan von Krawczynski
2001-10-16 23:38 ` VM Andrea Arcangeli
2001-10-17 0:49 ` VM Rik van Riel
2001-10-17 1:15 ` VM Andrea Arcangeli
2001-10-16 13:51 ` VM Bill Davidsen
2001-10-16 8:08 ` VM Alan Cox
[not found] <E7405EE40489D411B30F00508BF38F8D049677E2@wlvexc01.diginsite.com>
2001-10-16 16:44 ` VM David Lang
2001-10-16 18:11 ` VM Rik van Riel
2001-10-16 22:31 ` VM Luigi Genoni
2001-10-17 2:31 VM Marcelo Roberto Jimenez
2001-10-17 7:55 VM Leeuw van der, Tim
2001-10-17 11:08 ` VM Liu Tao
2001-10-22 13:36 VM Michael T. Babcock
2001-10-22 14:02 ` VM Alan Cox
2001-10-22 18:00 ` VM Mike Fedyk
2001-10-22 17:32 ` VM Marcelo Tosatti
2001-10-22 18:59 ` VM Daniel Phillips
2001-10-22 22:10 ` VM Ed Tomlinson
2001-10-23 5:37 ` VM Keith Owens
2001-10-23 5:38 ` VM Keith Owens
2001-10-23 16:15 ` VM Daniel Phillips
2001-10-23 16:14 ` VM David Lang
2001-10-24 13:54 ` VM J . A . Magallon
2001-10-24 18:11 ` VM Luigi Genoni
2001-10-24 14:44 ` VM Daniel Phillips
2001-10-24 16:24 ` VM David Lang
2001-10-24 17:56 ` VM Daniel Phillips
2001-10-24 16:50 ` VM David Lang
2001-10-24 18:29 ` VM Daniel Phillips
2001-10-22 20:21 ` VM Alan Cox
2001-10-22 22:35 ` VM J . A . Magallon
2001-10-22 21:33 VM Marcelo Roberto Jimenez
2001-10-22 21:44 ` VM Oliver Xymoron
2001-10-23 4:27 ` VM Patrick McFarland
2001-10-23 20:04 ` VM bill davidsen
2001-10-23 20:13 ` VM Rik van Riel
2001-10-23 22:15 ` VM Patrick McFarland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011016050739Z278091-17409+653@vger.kernel.org \
--to=safemode@speakeasy.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®