concurrent VM subsystems

concurrent VM subsystems

[Marton Kadar]

Just an idea from an absolute layman who keeps
an eye on Kernel Traffic:

Isn't it possible to include both VM approaches in the
kernel sources? It would be nice to be able to choose
at compile time through a configuration option.
Perhaps Andrea Arcangeli's version could be marked 
experimental.

Re: concurrent VM subsystems

[Reid Hekman]

Marton Kadar wrote:

> Just an idea from an absolute layman who keeps
> an eye on Kernel Traffic:
> 
> Isn't it possible to include both VM approaches in the
> kernel sources? It would be nice to be able to choose
> at compile time through a configuration option.
> Perhaps Andrea Arcangeli's version could be marked 
> experimental.


We've been over this already, while it would be nice for testing if the

two VM's could be compared without all the extra variables of the Linus
and -ac trees it's not going to happen. It would be a big headache to 
maintain all the extra source that would involve and all the changes to 
other stuff you'd have to patch to make the two interchangeable. This 
has been discussed for almost a week now and I'm sure it will show up
in next weeks kernel-traffic. I'd encourage layperson's to wait till
then to see how this story continues. <announcer_voice> So until next
week dear viewers! Same bat-time, same bat-channel!</announcer_voice>


If you're interested in seeing some of the discussion, here's a
reasonable jump off point in the archives...

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0110.2/1149.html



Just trying to better the signal-to-noise on linux-kernel...
Regards,
Reid

Re: concurrent VM subsystems

[Lars Marowsky-Bree]

On 2001-10-25T06:15:24,
   Reid Hekman <reid.hekman@ndsu.nodak.edu> said:

> We've been over this already, while it would be nice for testing if the
> 
> two VM's could be compared without all the extra variables of the Linus
> and -ac trees it's not going to happen. It would be a big headache to 
> maintain all the extra source that would involve and all the changes to 
> other stuff you'd have to patch to make the two interchangeable. 

Now, this might be 2.5 material, but I think the subsystem should be
modularized; I think it has been proven that this part of the code is
definitely subject for discussion, and I would go as far as saying it just
might be possible that the optimal VM, catering to different approaches, plain
out doesn't exist, and that being able to switch VM personalities during
runtime would be useful.

Fortifying the subsystem borders would also make debugging and testing easier.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

Re: concurrent VM subsystems

[Luigi Genoni]

This proposal came out two or three times.
Alan said "too ugly for words".

But the point is that when you are managing a complex project like the
Linux Kernel, you have to make choices, the VM is one of the think
that the tree manteiner has to make a choice about.

Two VM for the same kernel is nonsense, also as a configuration option.

In fact, here is the difference beetwen a coordinate and managed project,
and the "lets' put all inside" approach.


That said.
Those two VM are good, but for different use, and different HW.
It is a choice also which main use the kernel should address as a target.

I already exposed my opinion, and both Andrea and Rik know it very well.
The VM for servers needs to be predictable, for desktops needs to be as
fast as possible, also if it is a little less predictable and stable (who
cares if you reboot you desktop once every two days?).

Linus and Alan do chice for their tree what they want to get as a target,
and which VM approach they want to develop.

To have competition this way is also good, because there can also be
cooperation and compenetration.

Two VM as optional choice for one kernel is a bad approach, and is not
metodologically correct. (as a paradox, so let's have two VFS, two network
layers...)

Luigi



On Thu, 25 Oct 2001, Marton Kadar wrote:

> Just an idea from an absolute layman who keeps
> an eye on Kernel Traffic:
>
> Isn't it possible to include both VM approaches in the
> kernel sources? It would be nice to be able to choose
> at compile time through a configuration option.
> Perhaps Andrea Arcangeli's version could be marked
> experimental.
>
>
> -
> 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/
>

RE: concurrent VM subsystems

[M. Edward Borasky]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Luigi Genoni
> Sent: Thursday, October 25, 2001 6:07 AM
> To: Marton Kadar
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: concurrent VM subsystems


> In fact, here is the difference beetwen a coordinate and managed project,
> and the "lets' put all inside" approach.

No, it is the difference between an orderly, predictable, SEI - CMM type
development process used in military projects and the "brutal meritocracy",
Darwinian, survival of the fittest, life-at-the-edge-of-chaos process used
with Linux.

> That said.
> Those two VM are good, but for different use, and different HW.
> It is a choice also which main use the kernel should address as a target.
>
> I already exposed my opinion, and both Andrea and Rik know it very well.
> The VM for servers needs to be predictable, for desktops needs to be as
> fast as possible, also if it is a little less predictable and stable (who
> cares if you reboot you desktop once every two days?).

And I've given my opinion, though perhaps not quite as simply as I could. My
opinion is that there should be *one* VM (and *one* scheduler) *tunable* to
the purpose of the computer, rather than one which is good for a desktop,
another for a uniprocessor server, another for a few processors and another
for "massively parallel" servers. Just out of curiosity, which of the two
VMs is better for "predictable servers" and which one is better for "who
cares if you reboot" desktops?

> To have competition this way is also good, because there can also be
> cooperation and compenetration.

Yes ... the "life at the edge of chaos" I spoke of earlier. But in the end,
a single tunable algorithm would be preferable in my book to doing *two*
kernel builds and *two* boots every time one wanted to benchmark VM! One can
waste *weeks* doing this, when a single tunable algorithm could be optimized
to a benchmark or a real workload in *minutes*! Really! Just *minutes*, if
you do it right! It's about respect for the customer's time -- a concept
that needs to be considered along with all the exciting raw computer science
we're doing. :-)
--
M. Edward (Ed) Borasky, Borasky Research
Relax! Run Your Own Brain with Neuro-Semantics!
http://www.borasky-research.net/Flyer.htm
mailto:znmeb@borasky-research.net
http://groups.yahoo.com/group/pdx-neuro-semantics

Q: How do you tell when a pineapple is ready to eat?
A: It picks up its knife and fork.

RE: concurrent VM subsystems

[Luigi Genoni]

On Thu, 25 Oct 2001, M. Edward Borasky wrote:

> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Luigi Genoni
> > Sent: Thursday, October 25, 2001 6:07 AM
> > To: Marton Kadar
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: concurrent VM subsystems
>
>
> > In fact, here is the difference beetwen a coordinate and managed project,
> > and the "lets' put all inside" approach.
>
> No, it is the difference between an orderly, predictable, SEI - CMM type
> development process used in military projects and the "brutal meritocracy",
> Darwinian, survival of the fittest, life-at-the-edge-of-chaos process used
> with Linux.
I hate a militar approach, and indeed I was not meaning that.
But also in a darwinian system, you have to make a choice.
Linus is right when he decide for one VM in his tree, so is Alan to choice
another for his own. They take a position in front of the users, and doing
so they
declare which way they are planning for the development.
In this particular darwinian system could happen that the VM for the 2.4
kernels will not be the one choosen
for the 2.5 series.  That is because one VM could be the best for present
situation, but the other
can be better for the future development. As you see this is not
life-at-the-edge-of-chaos. On this point of view, I do trust both Linus
and Alan, that they do a well pondered choice, corresponding to the idea
they have, and to their plan, for the development they want for their
tree.
A darwinian system is very ordered, belive me, is very far from chaos.
 > > That
said. > > Those two VM are good, but for different use, and different HW.
> > It is a choice also which main use the kernel should address as a target.
> >
> > I already exposed my opinion, and both Andrea and Rik know it very well.
> > The VM for servers needs to be predictable, for desktops needs to be as
> > fast as possible, also if it is a little less predictable and stable (who
> > cares if you reboot you desktop once every two days?).
>
> And I've given my opinion, though perhaps not quite as simply as I could. My
> opinion is that there should be *one* VM (and *one* scheduler) *tunable* to
> the purpose of the computer, rather than one which is good for a desktop,
> another for a uniprocessor server, another for a few processors and another
> for "massively parallel" servers. Just out of curiosity, which of the two
> VMs is better for "predictable servers" and which one is better for "who
> cares if you reboot" desktops?
In the perfect OS there is just one VM that is perfect for every use with
every hardware, and every kind of architectures. But is there would be a
perfect OS, we would not need to do any development.
And you are right, the VM should be tunable (see latest AA patches),
but anyway you will have to deal with practical limits.
AA VM, in my tests, showed to be better for
my web servers anmd db, also if there are some details that should be
refined, (Andrea, I sended you the test case), On the other side Rik VM is
better in very particolar HI load, (on sparc64 in my tests), sytuations.
In my opinion, its just now, after we reach a good stability, that we can
start to tune for speed of the VM. I think to servers, because that is
what I have in my hands, and I talk for my esperience.
For servers stability is more important than speed, but when stability is
satisfying, then you
should start to tune for speed, to get the best performance.
 >
> > To have competition this way is also good, because there can also be
> > cooperation and compenetration.
>
> Yes ... the "life at the edge of chaos" I spoke of earlier. But in the end,
> a single tunable algorithm would be preferable in my book to doing *two*
> kernel builds and *two* boots every time one wanted to benchmark VM! One can
> waste *weeks* doing this, when a single tunable algorithm could be optimized
> to a benchmark or a real workload in *minutes*! Really! Just *minutes*, if
> you do it right! It's about respect for the customer's time -- a concept
> that needs to be considered along with all the exciting raw computer science
> we're doing. :-)
That is what system managers are for.
That is also what I like of my job. I have to deal every day with similar
choice with every Unix system I administer. Sometimes
I also need to move cpus and memory beetwen the E!=Ks domains, because
I have to do this to get the work done with full stability and fastly
(BTW, with linux domains I cannot do that without a bring up, and that
forbits me to use linux domains for serious things on E10Ks).

Luigi

> --
> M. Edward (Ed) Borasky, Borasky Research
> Relax! Run Your Own Brain with Neuro-Semantics!
> http://www.borasky-research.net/Flyer.htm
> mailto:znmeb@borasky-research.net
> http://groups.yahoo.com/group/pdx-neuro-semantics
>
> Q: How do you tell when a pineapple is ready to eat?
> A: It picks up its knife and fork.
>
> -
> 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/
>

Re: concurrent VM subsystems

[CaT]

On Thu, Oct 25, 2001 at 03:06:51PM +0200, Luigi Genoni wrote:
> I already exposed my opinion, and both Andrea and Rik know it very well.
> The VM for servers needs to be predictable, for desktops needs to be as
> fast as possible, also if it is a little less predictable and stable (who
> cares if you reboot you desktop once every two days?).

It doesn't matter if it's every 2 days or 2 years if it does it just
when you're doing something that must NOT be interrupted and you lose
a buttload of work. Stability is important in both a server AND desktop
environment.

-- 
CaT        "As you can expect it's really affecting my sex life. I can't help
           it. Each time my wife initiates sex, these ejaculating hippos keep
           floating through my mind."
                - Mohd. Binatang bin Goncang, Singapore Zoological Gardens

Re: concurrent VM subsystems

[Luigi Genoni]

Obviously I was not meaning that desktops have not to be stable, but they
are not subjects to long uptimes, at less usually, so page aging is,
how can I say in correct english?, dealing with different conditions...

Luigi


On Fri, 26 Oct 2001, CaT wrote:

> On Thu, Oct 25, 2001 at 03:06:51PM +0200, Luigi Genoni wrote:
> > I already exposed my opinion, and both Andrea and Rik know it very well.
> > The VM for servers needs to be predictable, for desktops needs to be as
> > fast as possible, also if it is a little less predictable and stable (who
> > cares if you reboot you desktop once every two days?).
>
> It doesn't matter if it's every 2 days or 2 years if it does it just
> when you're doing something that must NOT be interrupted and you lose
> a buttload of work. Stability is important in both a server AND desktop
> environment.
>
> --
> CaT        "As you can expect it's really affecting my sex life. I can't help
>            it. Each time my wife initiates sex, these ejaculating hippos keep
>            floating through my mind."
>                 - Mohd. Binatang bin Goncang, Singapore Zoological Gardens
>

Re: concurrent VM subsystems

[CaT]

On Fri, Oct 26, 2001 at 12:35:03AM +0200, Luigi Genoni wrote:
> Obviously I was not meaning that desktops have not to be stable, but they
> are not subjects to long uptimes, at less usually, so page aging is,
> how can I say in correct english?, dealing with different conditions...

No. That made more sense so you're fine. Still, not everyone turns them
on only for a few hours or so. For example, I have 2-4 day uptimes on my
laptop (the power of suspend to disk/ram :) so something that'll eventually
snog up on me simply because I didn't turn my laptop -off- would be damned
annoying.

-- 
CaT        "As you can expect it's really affecting my sex life. I can't help
           it. Each time my wife initiates sex, these ejaculating hippos keep
           floating through my mind."
                - Mohd. Binatang bin Goncang, Singapore Zoological Gardens

Re: concurrent VM subsystems

[Rik van Riel]

On Fri, 26 Oct 2001, Luigi Genoni wrote:

> Obviously I was not meaning that desktops have not to be stable, but
> they are not subjects to long uptimes, at less usually, so page aging
> is, how can I say in correct english?, dealing with different
> conditions...

Interestingly, of all the people saying that we should have
different VM systems for different situations, NOBODY has
managed to point out what specific things should be different.

The current situation of having 2 competing VMs seems to work
out nicely, though. Especially when ideas get merged all the
time.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/