Re: VM

Re: VM

[Marcelo Roberto Jimenez]

Alan Cox wrote:
> > > Too ugly for words.
> >
> > Though, if it's done from the start of 2.5, it could be very possible. 
> > Is there a way to make it non-ugly?
> 
> I would hope by then we have a definitive answer as to the best path in 
> the VM world

Maybe there's no such answer. Maybe it's undecidable. In the mathematical  (Gödel) sense.

Marcelo.

Re: VM

[Oliver Xymoron]

On Mon, 22 Oct 2001, Marcelo Roberto Jimenez wrote:

> Alan Cox wrote:
> > > > Too ugly for words.
> > >
> > > Though, if it's done from the start of 2.5, it could be very possible.
> > > Is there a way to make it non-ugly?
> >
> > I would hope by then we have a definitive answer as to the best path in
> > the VM world
>
> Maybe there's no such answer. Maybe it's undecidable. In the
> mathematical (Gödel) sense.

In the event that we're unable to determine which one has the best
performance in a finite amount of time, the simpler design wins.
So there will be a decision.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: VM

[Patrick McFarland]

Slightly off topic, but I kinda find it cool that this thread is still going, seeing as I started it on the 15th. =)

Anyhow, have we decided that 2.5 should have the ac-vm or the linus-vm?

On 22-Oct-2001, Oliver Xymoron wrote:
> On Mon, 22 Oct 2001, Marcelo Roberto Jimenez wrote:
> 
> > Alan Cox wrote:
> > > > > Too ugly for words.
> > > >
> > > > Though, if it's done from the start of 2.5, it could be very possible.
> > > > Is there a way to make it non-ugly?
> > >
> > > I would hope by then we have a definitive answer as to the best path in
> > > the VM world
> >
> > Maybe there's no such answer. Maybe it's undecidable. In the
> > mathematical (G?del) sense.
> 
> In the event that we're unable to determine which one has the best
> performance in a finite amount of time, the simpler design wins.
> So there will be a decision.
> 
> --
>  "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
> 
> -
> 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/
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[bill davidsen]

In article <20011023002702.A2446@localhost>,
Patrick McFarland <unknown@panax.com> wrote:
| Slightly off topic, but I kinda find it cool that this thread is still going, seeing as I
| started it on the 15th. =)
| 
| Anyhow, have we decided that 2.5 should have the ac-vm or the linus-vm?

I hope not, the bug-fix and corner case competition is doing good thing
for VM in both directions. That's healthy.

What I would like to see is VM moved to a module so you could have
either, or any of several competing designs which would be bound to
emerge once there's a neat interface and you can write to that instead
of trying to understand and hack all the stuff needed now. The effort is
high and the chance for problems high as well right now, in other words
a high ratio of implementation to method expertise.

I also would love to see the dispatcher moved to a module, so people can
easily play with ideas like the idle process, integrating VM and
dispatch operation at high memory load, etc.

Right now you not only need to understand the topic, but the
implementation. The implementation could be made easier with a clean
interface and an easy way to load changes for test without compiling a
kernel.

<BOOM>
  Yes, I'm still beating the drum for those modules.
</BOOM>

-- 
bill davidsen <davidsen@tmr.com>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.

Re: VM

[Rik van Riel]

On Tue, 23 Oct 2001, bill davidsen wrote:

> <BOOM>
>   Yes, I'm still beating the drum for those modules.
> </BOOM>

Send patches. ;)

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

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

Re: VM

[Patrick McFarland]

On 23-Oct-2001, bill davidsen wrote:
> In article <20011023002702.A2446@localhost>,
> Patrick McFarland <unknown@panax.com> wrote:
> | Slightly off topic, but I kinda find it cool that this thread is still going, seeing as I
> | started it on the 15th. =)
> | 
> | Anyhow, have we decided that 2.5 should have the ac-vm or the linus-vm?
> 
> I hope not, the bug-fix and corner case competition is doing good thing
> for VM in both directions. That's healthy.
> 
> What I would like to see is VM moved to a module so you could have
> either, or any of several competing designs which would be bound to
> emerge once there's a neat interface and you can write to that instead
> of trying to understand and hack all the stuff needed now. The effort is
> high and the chance for problems high as well right now, in other words
> a high ratio of implementation to method expertise.
> 
That module idea was mine, btw. Rik will speak up on that too, cause I was talking to him about it. =) I dont like having to run ac just for the better vm engine.

> I also would love to see the dispatcher moved to a module, so people can
> easily play with ideas like the idle process, integrating VM and
> dispatch operation at high memory load, etc.
> 
> Right now you not only need to understand the topic, but the
> implementation. The implementation could be made easier with a clean
> interface and an easy way to load changes for test without compiling a
> kernel.
> 
> <BOOM>
>   Yes, I'm still beating the drum for those modules.
> </BOOM>
> 
> -- 
> bill davidsen <davidsen@tmr.com>
>   His first management concern is not solving the problem, but covering
> his ass. If he lived in the middle ages he'd wear his codpiece backward.
> -
> 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/
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[Michael T. Babcock]

 > I've not reached any final conclusions on the VM - there are things that
 > Rik's VM shows up that look like the VM algorithm is right but it
 > triggers other stuff, and there are a couple of hackish bits left in 
still.

I have never done this comparison myself, but I was wondering how ugly 
it would be if stable versions of Andrea's and Rik's VMs were both 
available in your/Linus' kernel as compile-time options.  Assuming that 
each provides better performance under certain conditions, wouldn't 
being able to choose a VM make sense, if they don't step on the rest of
the kernel too much ...

-- 
Michael T. Babcock
http://www.fibrespeed.net/~mbabcock

Re: VM

[Alan Cox]

> I have never done this comparison myself, but I was wondering how ugly 
> it would be if stable versions of Andrea's and Rik's VMs were both 
> available in your/Linus' kernel as compile-time options.  Assuming that 
> each provides better performance under certain conditions, wouldn't 

Too ugly for words.

Re: VM

[Mike Fedyk]

On Mon, Oct 22, 2001 at 03:02:49PM +0100, Alan Cox wrote:
> > I have never done this comparison myself, but I was wondering how ugly 
> > it would be if stable versions of Andrea's and Rik's VMs were both 
> > available in your/Linus' kernel as compile-time options.  Assuming that 
> > each provides better performance under certain conditions, wouldn't 
> 
> Too ugly for words.

Though, if it's done from the start of 2.5, it could be very possible.  Is
there a way to make it non-ugly?

Re: VM

[Marcelo Tosatti]

On Mon, 22 Oct 2001, Mike Fedyk wrote:

> On Mon, Oct 22, 2001 at 03:02:49PM +0100, Alan Cox wrote:
> > > I have never done this comparison myself, but I was wondering how ugly 
> > > it would be if stable versions of Andrea's and Rik's VMs were both 
> > > available in your/Linus' kernel as compile-time options.  Assuming that 
> > > each provides better performance under certain conditions, wouldn't 
> > 
> > Too ugly for words.
> 
> Though, if it's done from the start of 2.5, it could be very possible.  Is
> there a way to make it non-ugly?

Even if its non-ugly, its non-easy. Way too much overhead.

For 2.5 we'll probably be able to get people working together. 

Re: VM

[Daniel Phillips]

On October 22, 2001 08:00 pm, Mike Fedyk wrote:
> On Mon, Oct 22, 2001 at 03:02:49PM +0100, Alan Cox wrote:
> > > I have never done this comparison myself, but I was wondering how ugly 
> > > it would be if stable versions of Andrea's and Rik's VMs were both 
> > > available in your/Linus' kernel as compile-time options.  Assuming that 
> > > each provides better performance under certain conditions, wouldn't 
> > 
> > Too ugly for words.
> 
> Though, if it's done from the start of 2.5, it could be very possible.  Is
> there a way to make it non-ugly?

No, not within the current structure of our config system.  It touches the 
tree in many places break out nicely into a few defines or separable files. 
Both mm variants are under heavy development and injecting them with a bunch 
of cruft just to make it compile-time configurable would only add to the 
difficulty of maintaining a subsystem that already is very difficult to 
maintain.

This is properly a patch.

If you want to argue for something, argue for giving config the ability to 
apply patches, that would be lots of fun.

--
Daniel

Re: VM

[Ed Tomlinson]

Daniel Phillips wrote:

> On October 22, 2001 08:00 pm, Mike Fedyk wrote:
>> On Mon, Oct 22, 2001 at 03:02:49PM +0100, Alan Cox wrote:
>> > > I have never done this comparison myself, but I was wondering how
>> > > ugly it would be if stable versions of Andrea's and Rik's VMs were
>> > > both
>> > > available in your/Linus' kernel as compile-time options.  Assuming
>> > > that each provides better performance under certain conditions,
>> > > wouldn't
>> > 
>> > Too ugly for words.
>> 
>> Though, if it's done from the start of 2.5, it could be very possible. 
>> Is there a way to make it non-ugly?
> 
> No, not within the current structure of our config system.  It touches the
> tree in many places break out nicely into a few defines or separable
> files. Both mm variants are under heavy development and injecting them
> with a bunch of cruft just to make it compile-time configurable would only
> add to the difficulty of maintaining a subsystem that already is very
> difficult to maintain.
> 
> This is properly a patch.
> 
> If you want to argue for something, argue for giving config the ability to
> apply patches, that would be lots of fun.

Actually this _is_ a workable solution.  IBM has done it for decades with 
its 'VM' operating system.

You get a base file, a couple of control files, and a lists of patches.  
When you go to build a nucleus (translate kernel) the patches are applied
and the source assembled...

Ed Tomlinson

Re: VM

[Keith Owens]

On Mon, 22 Oct 2001 18:10:44 -0400, 
Ed Tomlinson <tomlins@CAM.ORG> wrote:
>Daniel Phillips wrote:
>> If you want to argue for something, argue for giving config the ability to
>> apply patches, that would be lots of fun.
>
>Actually this _is_ a workable solution.  IBM has done it for decades with 
>its 'VM' operating system.
>
>You get a base file, a couple of control files, and a lists of patches.  
>When you go to build a nucleus (translate kernel) the patches are applied
>and the source assembled...

Same with the other mainframe systems, using something like SMP (System
Mangling/Management Product) to track the interdependencies.  But that
only works when almost all of the patches come from a single source
which does integration testing before releasing them.  This method does
not work well with multiple sources, look at the hassles third party
vendors have to go through to keep up with IBM patches.

Keith Owens (who spent far too many years fighting SMP)

Re: VM

[Keith Owens]

On Mon, 22 Oct 2001 20:59:40 +0200, 
Daniel Phillips <phillips@bonn-fries.net> wrote:
>If you want to argue for something, argue for giving config the ability to 
>apply patches, that would be lots of fun.

cc list trimmed.

It is kbuild rather than config that needs the ability.  I could do it
trivially in kbuild 2.5, I almost added the facility at one time.  Alas
it breaks when you get overlapping patches, select one config or
another and it works, select both (assuming they are not exclusive) and
it breaks.

I don't have a solution and the symptoms of overlapping patches are
worse than the problem that patches are trying to fix, so I left patch
support out of kbuild 2.5.  You can use shadow trees where you overlay
a new implementation of a subsystem over the base kernel, then switch
between versions by specifying which set of trees you are using.

http://sourceforge.net/projects/kbuild

Re: VM

[Daniel Phillips]

On October 23, 2001 07:38 am, Keith Owens wrote:
> Daniel Phillips <phillips@bonn-fries.net> wrote:
> >If you want to argue for something, argue for giving config the ability to 
> >apply patches, that would be lots of fun.
> 
> It is kbuild rather than config that needs the ability.  I could do it
> trivially in kbuild 2.5, I almost added the facility at one time.  Alas
> it breaks when you get overlapping patches, select one config or
> another and it works, select both (assuming they are not exclusive) and
> it breaks.

Yes, if someone was determined to set this up they'd have to laboriously 
break up overlapping patches into common vs independent pieces, and determine 
that other patches are simply mutually incompatible, thus requiring suitable 
config rule restrictions.  Wow, way too much work for the tree owner, and 
things will re-break frequently when the patch owner makes updates.

Maybe this technique is something that would interest the FOLK guys, where 
the goal is to produce a single tree with as many options as possible, and 
where they're willing to put in extra maintainance work.  Besides the two VM 
designs, there's the XFS patch, which we don't have a good way of integrating 
into a single tree just yet.

Please treat the above as idle speculation.  It's evident that including 
patches in kbuild is an express route to madness.  For one thing, I'd no 
longer be able to index the complete source tree for browsing.

> I don't have a solution and the symptoms of overlapping patches are
> worse than the problem that patches are trying to fix, so I left patch
> support out of kbuild 2.5.  You can use shadow trees where you overlay
> a new implementation of a subsystem over the base kernel, then switch
> between versions by specifying which set of trees you are using.

--
Daniel

Re: VM

[David Lang]

Daniel, I think the suggestion isn't to break out the differences in a
bunch of config options, but rather to do something like duplicating all
files that are VM related into two files, foo.c becomes foo.aa.c and
foo.rik.c at that point your config file either uses all the .rik files or
all the .aa files and both would be in the same tree, but not interact
with each other.

yes, there would be a lot of duplication between them, but something like
this would let people compare the two directly without also having all the
other linus vs ac changes potentially affecting their tests.

David Lang

 On Tue, 23 Oct 2001, Daniel Phillips wrote:

> Date: Tue, 23 Oct 2001 18:15:36 +0200
> From: Daniel Phillips <phillips@bonn-fries.net>
> To: Keith Owens <kaos@ocs.com.au>
> Cc: Linux Kernel <linux-kernel@vger.kernel.org>
> Subject: Re: VM
>
> On October 23, 2001 07:38 am, Keith Owens wrote:
> > Daniel Phillips <phillips@bonn-fries.net> wrote:
> > >If you want to argue for something, argue for giving config the ability to
> > >apply patches, that would be lots of fun.
> >
> > It is kbuild rather than config that needs the ability.  I could do it
> > trivially in kbuild 2.5, I almost added the facility at one time.  Alas
> > it breaks when you get overlapping patches, select one config or
> > another and it works, select both (assuming they are not exclusive) and
> > it breaks.
>
> Yes, if someone was determined to set this up they'd have to laboriously
> break up overlapping patches into common vs independent pieces, and determine
> that other patches are simply mutually incompatible, thus requiring suitable
> config rule restrictions.  Wow, way too much work for the tree owner, and
> things will re-break frequently when the patch owner makes updates.
>
> Maybe this technique is something that would interest the FOLK guys, where
> the goal is to produce a single tree with as many options as possible, and
> where they're willing to put in extra maintainance work.  Besides the two VM
> designs, there's the XFS patch, which we don't have a good way of integrating
> into a single tree just yet.
>
> Please treat the above as idle speculation.  It's evident that including
> patches in kbuild is an express route to madness.  For one thing, I'd no
> longer be able to index the complete source tree for browsing.
>
> > I don't have a solution and the symptoms of overlapping patches are
> > worse than the problem that patches are trying to fix, so I left patch
> > support out of kbuild 2.5.  You can use shadow trees where you overlay
> > a new implementation of a subsystem over the base kernel, then switch
> > between versions by specifying which set of trees you are using.
>
> --
> Daniel
> -
> 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: VM

[J . A . Magallon]

On 20011023 David Lang wrote:
>Daniel, I think the suggestion isn't to break out the differences in a
>bunch of config options, but rather to do something like duplicating all
>files that are VM related into two files, foo.c becomes foo.aa.c and
>foo.rik.c at that point your config file either uses all the .rik files or
>all the .aa files and both would be in the same tree, but not interact
>with each other.
>

Could it be as simple as duplicating linux/mm subtree to mm-aa and mm-rik,
and symlinking based on a CONFIG_ option ? Or are there any other touched
files apart from that subtree ?

Or just adding separate config options, *config-aa and *config-rik,
that make the symlink and call *config ?

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.12-ac6-beo #1 SMP Tue Oct 23 21:24:30 CEST 2001 i686

Re: VM

[Luigi Genoni]

UGLY!
two VM is one kernel is a nonsense. To develop an OS you have to do also
choices like this. I already wrote what i think of those VMs, they
are both usefull, but with different conditions and with different
worksload and HWs, depending on the behaviour you need.
Rik and Andrea know my point of view, I need a predictable VM for mission
critical USE, on desktop people will need the fastest VM for low memory
systems.
But to manage the development implys a choice, that could be different
for different branches, but anyway someone has to say, "This is the
right VM for this kernel, for what I think this kernel should
do"!

Luigi


On Wed, 24 Oct 2001, J . A . Magallon wrote:

>
> On 20011023 David Lang wrote:
> >Daniel, I think the suggestion isn't to break out the differences in a
> >bunch of config options, but rather to do something like duplicating all
> >files that are VM related into two files, foo.c becomes foo.aa.c and
> >foo.rik.c at that point your config file either uses all the .rik files or
> >all the .aa files and both would be in the same tree, but not interact
> >with each other.
> >
>
> Could it be as simple as duplicating linux/mm subtree to mm-aa and mm-rik,
> and symlinking based on a CONFIG_ option ? Or are there any other touched
> files apart from that subtree ?
>
> Or just adding separate config options, *config-aa and *config-rik,
> that make the symlink and call *config ?
>
> --
> J.A. Magallon                           #  Let the source be with you...
> mailto:jamagallon@able.es
> Mandrake Linux release 8.2 (Cooker) for i586
> Linux werewolf 2.4.12-ac6-beo #1 SMP Tue Oct 23 21:24:30 CEST 2001 i686
> -
> 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: VM

[Daniel Phillips]

On October 23, 2001 06:14 pm, David Lang wrote:
> Daniel, I think the suggestion isn't to break out the differences in a
> bunch of config options, but rather to do something like duplicating all
> files that are VM related into two files, foo.c becomes foo.aa.c and
> foo.rik.c at that point your config file either uses all the .rik files or
> all the .aa files and both would be in the same tree, but not interact
> with each other.
> 
> yes, there would be a lot of duplication between them, but something like
> this would let people compare the two directly without also having all the
> other linus vs ac changes potentially affecting their tests.

Patch and lilo are your friends.

--
Daniel

Re: VM

[David Lang]

the problem is that there isn't a patchset available from either aa or rik
that converts one to the other, the only patchset readily available
converts linus+aa to ac+rik this changes a lot more then just the VM stuff
so without going to a lot of effort it's not possible to directly compare
the two VM designs while keeping the rest of the kernel the same.

David Lang



 On Wed, 24 Oct 2001, Daniel Phillips wrote:

> Date: Wed, 24 Oct 2001 16:44:53 +0200
> From: Daniel Phillips <phillips@bonn-fries.net>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Keith Owens <kaos@ocs.com.au>,
>      Linux Kernel <linux-kernel@vger.kernel.org>
> Subject: Re: VM
>
> On October 23, 2001 06:14 pm, David Lang wrote:
> > Daniel, I think the suggestion isn't to break out the differences in a
> > bunch of config options, but rather to do something like duplicating all
> > files that are VM related into two files, foo.c becomes foo.aa.c and
> > foo.rik.c at that point your config file either uses all the .rik files or
> > all the .aa files and both would be in the same tree, but not interact
> > with each other.
> >
> > yes, there would be a lot of duplication between them, but something like
> > this would let people compare the two directly without also having all the
> > other linus vs ac changes potentially affecting their tests.
>
> Patch and lilo are your friends.
>
> --
> Daniel
>

Re: VM

[Daniel Phillips]

On October 24, 2001 06:24 pm, David Lang wrote:
> the problem is that there isn't a patchset available from either aa or rik
> that converts one to the other, the only patchset readily available
> converts linus+aa to ac+rik this changes a lot more then just the VM stuff
> so without going to a lot of effort it's not possible to directly compare
> the two VM designs while keeping the rest of the kernel the same.

A non-kernel-hacker can easily make the patch.  Andrea posted a list of all 
the files affected back at the beginning of his 'vm rewrite' thread.

> > > Daniel, I think the suggestion isn't to break out the differences in a
> > > bunch of config options, but rather to do something like duplicating all
> > > files that are VM related into two files, foo.c becomes foo.aa.c and
> > > foo.rik.c at that point your config file either uses all the .rik files 
> > > or all the .aa files and both would be in the same tree, but not 
> > > interact with each other.
> > >
> > > yes, there would be a lot of duplication between them, but something 
> > > like this would let people compare the two directly without also having 
> > > all the other linus vs ac changes potentially affecting their tests.
> >
> > Patch and lilo are your friends.

--
Daniel

Re: VM

[David Lang]

those were the files that his patches were changing, since then we also
have had linus, rik and alan making changes in the various trees.

are you willing to bet that the only changes in those files are related to
the VM system changes and that there are no other -ac related changes in
those files due to the other ac changes? without someone who really
understands the rik VM I wouldn't trust breaking them out of the -ac
tree and the same thing goes for the aa VM and the linus tree (to add that
into the ac tree)

as I see it this requires a few steps.

1. linus and alan agree to implement such a thing (which includes
alanbeing willing to track the appropriate differences)

2. rik and/or aa and/or alan seperate out the rik VM from the ac tree and
submit it to linus.

3. rik and/or aa and/or alan seperate out the aa VM from the linus tree
and submit it to alan.

it's a lot of work to get it setup this way, and it does duplicate a bunch
of files that could get out of sync if not carefully managed but it's
about the only way that I can see people able to test just the different
VM systems.

now if one of the above four states that there are files (or directories)
that are only the VM system and it is as simple as swapping out everything
in those files between the linus and ac trees then steps 2&3 get much
simpler.

David Lang

On Wed, 24 Oct 2001, Daniel Phillips wrote:

> Date: Wed, 24 Oct 2001 19:56:00 +0200
> From: Daniel Phillips <phillips@bonn-fries.net>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Keith Owens <kaos@ocs.com.au>,
>      Linux Kernel <linux-kernel@vger.kernel.org>
> Subject: Re: VM
>
> On October 24, 2001 06:24 pm, David Lang wrote:
> > the problem is that there isn't a patchset available from either aa or rik
> > that converts one to the other, the only patchset readily available
> > converts linus+aa to ac+rik this changes a lot more then just the VM stuff
> > so without going to a lot of effort it's not possible to directly compare
> > the two VM designs while keeping the rest of the kernel the same.
>
> A non-kernel-hacker can easily make the patch.  Andrea posted a list of all
> the files affected back at the beginning of his 'vm rewrite' thread.
>
> > > > Daniel, I think the suggestion isn't to break out the differences in a
> > > > bunch of config options, but rather to do something like duplicating all
> > > > files that are VM related into two files, foo.c becomes foo.aa.c and
> > > > foo.rik.c at that point your config file either uses all the .rik files
> > > > or all the .aa files and both would be in the same tree, but not
> > > > interact with each other.
> > > >
> > > > yes, there would be a lot of duplication between them, but something
> > > > like this would let people compare the two directly without also having
> > > > all the other linus vs ac changes potentially affecting their tests.
> > >
> > > Patch and lilo are your friends.
>
> --
> Daniel
>

Re: VM

[Daniel Phillips]

On October 24, 2001 06:50 pm, David Lang wrote:
> those were the files that his patches were changing, since then we also
> have had linus, rik and alan making changes in the various trees.
> 
> are you willing to bet that the only changes in those files are related to
> the VM system changes and that there are no other -ac related changes in
> those files due to the other ac changes? without someone who really
> understands the rik VM I wouldn't trust breaking them out of the -ac
> tree and the same thing goes for the aa VM and the linus tree (to add that
> into the ac tree)
> 
> as I see it this requires a few steps.
> 
> 1. linus and alan agree to implement such a thing (which includes
> alanbeing willing to track the appropriate differences)

My advice is: don't try to waste Linus's or Alan's time on this.  Just make 
the patch, it isn't that hard.  Just post it, and if you get it partly wrong 
Rik and/or Andrea will be sure to tell you.

> 2. rik and/or aa and/or alan seperate out the rik VM from the ac tree and
> submit it to linus.
> 
> 3. rik and/or aa and/or alan seperate out the aa VM from the linus tree
> and submit it to alan.
> 
> it's a lot of work to get it setup this way, and it does duplicate a bunch
> of files that could get out of sync if not carefully managed but it's
> about the only way that I can see people able to test just the different
> VM systems.

So why are you asking developers who have plenty of other things to do, to do 
that work?

> now if one of the above four states that there are files (or directories)
> that are only the VM system and it is as simple as swapping out everything
> in those files between the linus and ac trees then steps 2&3 get much
> simpler.

Do it whatever way you want, that's why you have the source.  I'd suggest 
'diff', starting with the files in Andrea's list.  Then edit the patch by 
hand, removing the chunks that obviously aren't related.

--
Daniel

Re: VM

[Alan Cox]

> > Too ugly for words.
> 
> Though, if it's done from the start of 2.5, it could be very possible.  Is
> there a way to make it non-ugly?

I would hope by then we have a definitive answer as to the best path in the
VM world

Re: VM

[J . A . Magallon]

On 20011022 Alan Cox wrote:
>> I have never done this comparison myself, but I was wondering how ugly 
>> it would be if stable versions of Andrea's and Rik's VMs were both 
>> available in your/Linus' kernel as compile-time options.  Assuming that 
>> each provides better performance under certain conditions, wouldn't 
>
>Too ugly for words.
>-

and how about a CONFIG_ ?? So -ac patch size will become manageable again.

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.12-ac5-beo #1 SMP Mon Oct 22 02:05:06 CEST 2001 i686

Re: VM

[Leeuw van der, Tim]

I've tried more-or-less comparable desktop workloads on various
kernel-versions.

So far my conclusion is that for desktops, the VM in the recent -ac kernels
is worst, the VM in Linus's recent kernels is much better for the desktop,
but that the kernel with the smoothest operation on the desktop is:

2.4.4ac8

(There are several 2.4.4-ac kernels with identical VM just I happen to have
this one installed as a sort of backup)

This is a really old kernel, and I know that there were problems with that
VM version under certain loads. Still, the fact that it performs well is
perhaps an interesting datapoint.
I don't know if problems in the 2.4.4-ac8 VM can be killed without also
killing the performance?

The tested load is:

- Compiling kernel
- Browsing web with Mozilla or Galeon
- Opening Evolution and looking at mail
- Editing files with XEmacs

My criteria were speed of opening new big applications when another big
application is running and compiling at the same time, how useable the
system is while the application starts up, how quickly and smoothly I can
switch from one app. to the other.

All of these are of course highly subjective criteria.

I'm not interested in audio, so I didn't do any tests for smoothness of
playing sound while doing any of these things.

Next weekend I hope to have time to give the VM's another try; this time
I'll apply relevant Rik's patches to the -ac kernel too.

My PC has 64MB of RAM and some slow IDE disks (tuned with DMA and -u 1), and
a 200MHz MMX P1


--Tim

Re: VM

[Liu Tao]

I tested "mtest01 -p 200 -w" on both 2.4.12-ac3 and 2.4.13pre3aa1,
in single mode both killed mtest01, but in kde 2.4.13pre3aa1 can't kill
mtest01 after a long wait, and I have to reset.

I have 128M ram, 500M swap on IDE disk, Celeron 433 cpu.

Regards
Liu Tao

Re: VM

[Marcelo Roberto Jimenez]

Folks,

Let's stop talking :-) and let's generate some numbers for comparison.

Rik, Andrea, why don't you describe a procedure to generate the numbers for comparison? I have both kernels installed on my machine, so it's easy for me to compare under different loads.

Of couse, I'm new to this stuff, forgive my ignorance :-)

Regards,

Marcelo.

Re: VM

[David Lang]

the previous non-Rik VM kernel (other then the current linus tree) is the
2.2 kernels, and they are lacking a LOT of features that are in 2.4

it's not a case of wanting to run 2.4.latest on production, it's a matter
of wanting to run 2.4.anything on production. currently this is a serious
problem to do becouse the VM system has not been stable and predictable
enough to be trusted. there have been to many cases of people putting 2.4
on a production system and it slowing to a crawl when the real production
load hits.

when 2.4 works it is FAR better then 2.2 and it has features not available
on 2.2, but with the Rik VM (versions that were in the linus kernels up
through 2.4.9) it has not reliably worked. running 2.4 is not supposed to
be bleading edge, it's supposed to be the stable kernel series (although
you do have to wait a few days after a kernel is released to avoid paper
bag bugs :-)

if we want a kernel series that should not be used in production servers
we need to get 2.4 stable enough to be used there and then we can open the
2.5 series

David Lang

On Tue, 16 Oct 2001, safemode wrote:
<SNIP>
> People who use the latest 2.4.x kernel aren't running critical servers,
> rebooting back to their previous non-Rik vm kernel wont be much of an issue.
> It wont "break" anything, rather just be better or worse performance wise.
> If you can afford to reboot to upgrade to the latest 2.4.x, you can afford to
> reboot to move back to your backup kernel.
> Makeing a standard way of testing "real world" things is bad.  Real world
> tests are unlimited and thus can be very hard to recreate but with this way
> you can actually see the "special" cases that become more apparent when more
> users use the kernel much earlier.  This would be the same as your statement
> above about releasing a bad kernel onto the public as a stable kernel.  If
> you tune to a standard real world test that some people come up with, then
> you are no longer tuning for the real world since you lose that
> unpredictability that real users can enter into the equation.
>
> Like i said before, tests are a lose lose situation,  if you dont do them you
> release code unto the world that is well, untested.  If you do them, then
> you're tuning for your test and not the real world and you have people saying
> that the test is invalid or biased.  Well, so far not using a test is out of
> the question and Both VM's certainly get their round of testing, the
> contraversy with that is what tests are important in the real world.  Figure
> that out and maybe you'll get somewhere with figuring out which VM is better
> for everyone.  If you manage to convince everyone that those tests are
> important to the real world, you're probably writing the code and/or a
> god-like being.
>

Re: VM

[Rik van Riel]

On Tue, 16 Oct 2001, David Lang wrote:

> when 2.4 works it is FAR better then 2.2 and it has features not
> available on 2.2, but with the Rik VM (versions that were in the linus
> kernels up through 2.4.9) it has not reliably worked.

Note that Linus hasn't been up to date on my VM since
about 2.4.5.  And before you blame me for not sending
patches, I did send them but Linus didn't apply them
for unknown reasons.

The VM in Alan's kernel pretty much has been the only
option for a reliable 2.4 kernel since 2.4.7.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

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

Re: VM

[Luigi Genoni]

On Tue, 16 Oct 2001, Rik van Riel wrote:

> On Tue, 16 Oct 2001, David Lang wrote:
>
> > when 2.4 works it is FAR better then 2.2 and it has features not
> > available on 2.2, but with the Rik VM (versions that were in the linus
> > kernels up through 2.4.9) it has not reliably worked.
>
> Note that Linus hasn't been up to date on my VM since
> about 2.4.5.  And before you blame me for not sending
> patches, I did send them but Linus didn't apply them
> for unknown reasons.
>
2.4.5 had a little showstopper problem with iommu, and so my old E 3500
was really suffering with it.
As you know, VM performances are not the first priority for some servers,
while they are for desktops and for servers used for computational
simulations. But right now, definitelly, we are not at the point we copuld
care of 5% faster or slower. What we do care right now is to have a VM
that works for the jobs we need to be done. Belive me, that is a good
thing, and this also explain why people write that the VM is great, and
other that the VM is a disaster.

Sometimes I do not understand Linus decisions, but history showed he is
Linus and I am a simple Sysadmin who trys to give his contrib.

I am not arguing your VM was overdesigned, and to be honest I simply do
not think so.

One thing that should be took in account is that your VM
in ac tree  before 2.4.9acX was behaving better on sparc64 than x86
processors. Belive me i stressed a ultra5 (400 Mhz sparc64 processor 512
Megabyte of RAM) with a 2.4.8ac(not remember exactly) kernel, and it was
stable under a very high load.
A mutch faster Athlon 1000 Mhz, with same amount of faster memory, and
same UDMA66 disk, showed a suffering VM even not being equally
stressed.
maybe your approach was better working on this kind of architecture. (I am
sorry I could not test some mips).
On the other side your VM has some behavious that remembers me of my old
AIX times :). (you know I tend to be a bit nostalgic).

On the other side, AA VM (2.4.13-pre3aa1) is exactly what I need on my
webservers. You VM is more effective on a higly stressed server running
hundreds of eavty and memory intensive simulations on it (and also in
this case, I do not care it to be the fastest, but it has to be adle to
bring simulations to work properly).

That brings me to the point I made in my previous post.

If you remember the oops I sended you a lot of months ago with 2.4.3,
it was related to a server that had not to be fast, but had to reach years
of uptime.

When i think to desktops, I change my mind, they have to be as faster as
possible.

Linux does work on any kind of CPU, from a domain on SUN E 10000, to a 386
sx 25Mhz, and potentially it can be used for everything. This brings a
critical complexity to the VM, and this makes development difficoult.
This is a situation we must deal with.

Luigi

VM

[Patrick McFarland]

Linus, this question is really to you...

Why is the simple vm system still in place on the linus tree? I would think the smart vm system in the ac tree would be better suited to .. oh.. say .. everything. (The potential for less swapping is _always better_)

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[David Lang]

from an interested bystander here's how I see it

much of the time the -ac VM is better, but sometimes it is MUCH worse.
It's performance can vary substantually even while running the same test.

the linux VM may not be as fast in some cases, but it is far more
predictable and repeatable, and doesn't have the same horrible 'worst
case' performance that has been the bane of the 2.4 kernels.

say for the sake of argument that the linus VM is only 80% as good as the
-ac VM. but the -ac VM has pathalogical conditions that hit is 5% of the
time (both numbers out of thin air, I'm sure that aa would argue that it's
better then the 80% and Rik would argue that it's less then 5% :-)

we're late in the 2.4 series, stability and predictability is better then
raw performance. the 5% pathalogical problem is bad enough to make that VM
unsuatable for many machines (and worse the conditions that trigger it
aren't well understood making it untrustworthy for a much larger group of
machines) while the slight performance hit on the 80% as good is much
easier to deal with (buy a faster disk or more ram)

I have been impressed by the repeatability shown by the linus VM system
and have just been waiting for the last of the gotchas to be hammered out
before switching my production machines from 2.4.5 to a newer kernel.

David Lang



 On Mon, 15
Oct 2001, Patrick McFarland wrote:

> Date: Mon, 15 Oct 2001 21:12:18 -0400
> From: Patrick McFarland <unknown@panax.com>
> To: linux-kernel@vger.kernel.org
> Subject: VM
>
> Linus, this question is really to you...
>
> Why is the simple vm system still in place on the linus tree? I would think the smart vm system in the ac tree would be better suited to .. oh.. say .. everything. (The potential for less swapping is _always better_)
>
> --
> Patrick "Diablo-D3" McFarland || unknown@panax.com
> -
> 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: VM

[John Levon]

On Mon, Oct 15, 2001 at 05:53:32PM -0700, David Lang wrote:

> before switching my production machines from 2.4.5 to a newer kernel.

running such an old kernel does not give a fair comparison. Personally I've
found the /current/ ac VM to be stable and give slightly smoother feel than
the linus tree VM.

regards
john

-- 
"I hear you have four hundred and eighty six PCs for sale ?"
	- Some Fool 

Re: VM

[Tobias Ringstrom]

On Tue, 16 Oct 2001, John Levon wrote:

> On Mon, Oct 15, 2001 at 05:53:32PM -0700, David Lang wrote:
> 
> > before switching my production machines from 2.4.5 to a newer kernel.
> 
> running such an old kernel does not give a fair comparison. Personally I've
> found the /current/ ac VM to be stable and give slightly smoother feel than
> the linus tree VM.

Are you comparing with post 2.4.10 Linus kernels?

/Tobias

Re: VM

[David Lang]

I'm not doing a comparison of the VM in 2.4.5 and the newer kernels, I'm
saying that based on the reports I have been seeing here I have not been
willing to risk moving to a newer kernel becouse I couldn't trust the VM
not to give me problems on my production boxes. the 2.4.5 has it's
problems, but they are survivable (except on one box which I had to
remove)

it's not a direct comparison of the kernels, it's a matter of being able
to trust that the new kernel won't hang me out to dry under load. (and I
am one of the many people out here who doesn't have the ability to
simulate the load before going into production)

David Lang


 On Tue, 16 Oct 2001, John Levon wrote:

> Date: Tue, 16 Oct 2001 13:28:51 +0100
> From: John Levon <moz@compsoc.man.ac.uk>
> To: linux-kernel@vger.kernel.org
> Subject: Re: VM
>
> On Mon, Oct 15, 2001 at 05:53:32PM -0700, David Lang wrote:
>
> > before switching my production machines from 2.4.5 to a newer kernel.
>
> running such an old kernel does not give a fair comparison. Personally I've
> found the /current/ ac VM to be stable and give slightly smoother feel than
> the linus tree VM.
>
> regards
> john
>
> --
> "I hear you have four hundred and eighty six PCs for sale ?"
> 	- Some Fool
> -
> 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: VM

[Linus Torvalds]

In article <20011015211216.A1314@localhost>,
Patrick McFarland  <unknown@panax.com> wrote:
>
>Why is the simple vm system still in place on the linus tree? I would
think the smart vm system in the ac tree would be better suited to .. 
oh..  say ..  everything.

"complex" != "smart".

The benchmarks I've seen says that the simple VM performs better - both
in terms of repeatability and in terms of absolute performance. Search
this list yourself if you don't believe me.

		Linus

Re: VM

[Patrick McFarland]

reading what lang wrote, ive been thinking

Im on the type of machine that swapping the least is most favorable. rik's vm seems that it would be able to swap less, and not swap the wrong things enough of the time. andrea's, if i try to do something major, it swaps like crazy, but I havent tested rik's because I dont trust the rest of the ac tree to mess around with it. Is there any chance of rik's vm being atleast an option to choose, and possibly see what the community wants? Maybe if rik's vm is cleaned up, that 5% of stupidity would go down to the less than 1% we all hope for. 

On 16-Oct-2001, Linus Torvalds wrote:
> In article <20011015211216.A1314@localhost>,
> Patrick McFarland  <unknown@panax.com> wrote:
> >
> >Why is the simple vm system still in place on the linus tree? I would
> think the smart vm system in the ac tree would be better suited to .. 
> oh..  say ..  everything.
> 
> "complex" != "smart".
> 
> The benchmarks I've seen says that the simple VM performs better - both
> in terms of repeatability and in terms of absolute performance. Search
> this list yourself if you don't believe me.
> 
> 		Linus
> -
> 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/
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[Robert Love]

On Mon, 2001-10-15 at 23:08, Patrick McFarland wrote:

> Im on the type of machine that swapping the least is most favorable. rik's vm
> seems that it would be able to swap less, and not swap the wrong things enough
> of the time. andrea's, if i try to do something major, it swaps like crazy,
> but I havent tested rik's because I dont trust the rest of the ac tree to mess
> around with it. Is there any chance of rik's vm being atleast an option to
> choose, and possibly see what the community wants? Maybe if rik's vm is
> cleaned up, that 5% of stupidity would go down to the less than 1% we all
> hope for.

There really is nothing to fear in Alan's tree.  Give it a tree.  In
fact, I view Alan as more stable (or at least, less experimental) at
this stage in the game.

	Robert Love

Re: VM

[Patrick McFarland]

May I ask, why do you think so?

On 15-Oct-2001, Robert Love wrote:
> On Mon, 2001-10-15 at 23:08, Patrick McFarland wrote:
> 
> > Im on the type of machine that swapping the least is most favorable. rik's vm
> > seems that it would be able to swap less, and not swap the wrong things enough
> > of the time. andrea's, if i try to do something major, it swaps like crazy,
> > but I havent tested rik's because I dont trust the rest of the ac tree to mess
> > around with it. Is there any chance of rik's vm being atleast an option to
> > choose, and possibly see what the community wants? Maybe if rik's vm is
> > cleaned up, that 5% of stupidity would go down to the less than 1% we all
> > hope for.
> 
> There really is nothing to fear in Alan's tree.  Give it a tree.  In
> fact, I view Alan as more stable (or at least, less experimental) at
> this stage in the game.
> 
> 	Robert Love
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[Robert Love]

On Mon, 2001-10-15 at 23:22, Patrick McFarland wrote:
> Okay, I might. Just a small question, tho, how often is ac patches put out
> on avg? Weekly? Biweekly?

Look at the timestamps.  A couple times a week to daily.  Note at this
point its all stable series stuff: driver updates, bug fixes, etc.

This is why Alan is stable.

	Robert Love

Re: VM

[safemode]

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.   

Re: VM

[David Lang]

and the problem with trying to do the perfect thing in every situation is
that you need to predict all the situations so that you have the right
response for each one.

it gets even worse when you have a mix of loads (parts of several
different basic situations).

this is why a simpler solution that may not be quite as good in several of
the simple situations can end up being a winner in the real world (where
you almost always have a mix of situations)

also if you have a lot of special cases you need to choose between you
can easily  end up spending more time selecting the proper mode then you
save by being in that mode

one thing that the entire 2.[34] VM hassle has shown is that the VM
hackers don't have a good handle on the real world loads along with a way
to reasonably duplicate those loads in testing (if anyone had any idea
what sort of VM problems 2.4 would have they would have been resolved in
the 2.3 series, right?) This makes simple/general solutions better then
attempts to define and select a bunch of special purpose solutions.

from the looks of things Rik's VM is getting to the point where it is
almost covering enough special cases to be practical, but for the reasons
I gave above I have less confidence in it then in the AA VM for the near
future. Long term may be a different story however.

One thing that I think is needed for future 2.4/2.5 before much more
VM development can be done is some significant instramentation of the
existing VM to gather data on real-world loads along with some simulater
to be able to recreate them. without this sort of data and tools the best
that the VM hackers can do is to test it on the machines and loads they
see and hope that they cover enough cases to make the special casing
approach work, otherwise we keep running the risk of the same type of
problems with the next implementation.

in part this is a chicken-and-egg problem, until the new VM gets extensive
real-world testing it won't run into all the corner cases to be able to
see if it works well but this also means that when released on the general
user base it will break peoples servers. thus the need for better
documentation and instramentation of the real world loads (becouse they
are frequently NOT the 'best' way of doing things and in some cases they
are downright bad ways)

David Lang



 On Tue, 16 Oct 2001, safemode wrote:

> Date: Tue, 16 Oct 2001 01:08:02 -0400
> From: safemode <safemode@speakeasy.net>
> To: linux-kernel@vger.kernel.org
> Subject: Re: VM
>
> 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.
> -
> 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: VM

[safemode]

On Tuesday 16 October 2001 00:40, David Lang wrote:
> and the problem with trying to do the perfect thing in every situation is
> that you need to predict all the situations so that you have the right
> response for each one.

predicting more situations ...not every situation.  Our brains aren't 
hardcoded with the knowledge of how to deal with everything ...that would be 
as impossible as predicting all situations dealing with VM.   Instead it 
looks at more variables and decides upon that what to do.  

> it gets even worse when you have a mix of loads (parts of several
> different basic situations).

This is where a complex solution can be better than a simple.  A mix of loads 
means you'll have different Kinds of programs....not just different programs, 
asking the VM for various things.  Because they're different kinds of 
programs they'll benefit from not being treated all under a vague reaction 
that would be given by a simplistic VM.  A simplistic solution may be faster 
in doing what it does, but in the real world time goes on from that point and 
what the VM did before effects what is happening later.  And overall a 
simplistic solution may actually hurt the performance of a VM.  

> this is why a simpler solution that may not be quite as good in several of
> the simple situations can end up being a winner in the real world (where
> you almost always have a mix of situations)

A complex solution (that works), will handle memory in a way that makes what 
is going to happen next, more efficient.  We see this in Rik's vm.  This 
makes overall VM performance much smoother and in most people's opinions, 
better.  

> also if you have a lot of special cases you need to choose between you
> can easily  end up spending more time selecting the proper mode then you
> save by being in that mode

True, but taking a tiny bit of time to find the right mode may save a lot of 
time in the long run by having memory allocated in a more efficient way for 
new accesses.  We see this from the VM being reported "more smooth".   The 
jerkiness in a vm is caused by having to correct a past operation that 
probably put too much memory somewhere it wasn't needed and now it needs it 
so it has to take the time to deallocate it and then allocate it to the new 
one. 

> one thing that the entire 2.[34] VM hassle has shown is that the VM
> hackers don't have a good handle on the real world loads along with a way
> to reasonably duplicate those loads in testing (if anyone had any idea
> what sort of VM problems 2.4 would have they would have been resolved in
> the 2.3 series, right?) This makes simple/general solutions better then
> attempts to define and select a bunch of special purpose solutions.

The thing with benchmarks is that you'll always have people saying they're 
not valid and people saying they are.  If you want to package a bunch of 
static binaries and write a script to time and give all sorts of stats while 
it runs them in some series or concurrently, go for it.  But even if you do 
and they're all programs most people run daily, people will still say that 
it's not valid due to compiler optimizations.  It's a lose-lose situation 
with testing.   The only way to do it is go with the majority's reaction to 
it on their own systems, there is no fast simulation way that will appease 
people. 

> from the looks of things Rik's VM is getting to the point where it is
> almost covering enough special cases to be practical, but for the reasons
> I gave above I have less confidence in it then in the AA VM for the near
> future. Long term may be a different story however.

Practicality is subjective obviously.   It depends on which definitions of 
stability and performance you are concerned with.  Both are valid in their 
areas of use but in the end what will determine which gets used is going to 
be just how much of a hit does Rik's vm do on servers and such by being 
complex and less predictable.  Just because it's less predictable doesn't 
mean it will hinder a running server in the long run, perhaps it'll be better 
for a server that stays up for a long time.  Only people running it will 
tell. 

> One thing that I think is needed for future 2.4/2.5 before much more
> VM development can be done is some significant instramentation of the
> existing VM to gather data on real-world loads along with some simulater
> to be able to recreate them. without this sort of data and tools the best
> that the VM hackers can do is to test it on the machines and loads they
> see and hope that they cover enough cases to make the special casing
> approach work, otherwise we keep running the risk of the same type of
> problems with the next implementation.
>
> in part this is a chicken-and-egg problem, until the new VM gets extensive
> real-world testing it won't run into all the corner cases to be able to
> see if it works well but this also means that when released on the general
> user base it will break peoples servers. thus the need for better
> documentation and instramentation of the real world loads (becouse they
> are frequently NOT the 'best' way of doing things and in some cases they
> are downright bad ways)

People who use the latest 2.4.x kernel aren't running critical servers, 
rebooting back to their previous non-Rik vm kernel wont be much of an issue. 
It wont "break" anything, rather just be better or worse performance wise.  
If you can afford to reboot to upgrade to the latest 2.4.x, you can afford to 
reboot to move back to your backup kernel. 
Makeing a standard way of testing "real world" things is bad.  Real world 
tests are unlimited and thus can be very hard to recreate but with this way 
you can actually see the "special" cases that become more apparent when more 
users use the kernel much earlier.  This would be the same as your statement 
above about releasing a bad kernel onto the public as a stable kernel.  If 
you tune to a standard real world test that some people come up with, then 
you are no longer tuning for the real world since you lose that 
unpredictability that real users can enter into the equation. 

Like i said before, tests are a lose lose situation,  if you dont do them you 
release code unto the world that is well, untested.  If you do them, then 
you're tuning for your test and not the real world and you have people saying 
that the test is invalid or biased.  Well, so far not using a test is out of 
the question and Both VM's certainly get their round of testing, the 
contraversy with that is what tests are important in the real world.  Figure 
that out and maybe you'll get somewhere with figuring out which VM is better 
for everyone.  If you manage to convince everyone that those tests are 
important to the real world, you're probably writing the code and/or a 
god-like being. 


> David Lang
>
>  On Tue, 16 Oct 2001, safemode wrote:
> > Date: Tue, 16 Oct 2001 01:08:02 -0400
> > From: safemode <safemode@speakeasy.net>
> > To: linux-kernel@vger.kernel.org
> > Subject: Re: VM
> >
> > 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.
> > -
> > 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: VM

[Allan Sandfeld]

On Tuesday 16 October 2001 15:34, safemode wrote:
> This is where a complex solution can be better than a simple.  A mix of
> loads means you'll have different Kinds of programs....not just different
> programs, asking the VM for various things.  Because they're different
> kinds of programs they'll benefit from not being treated all under a vague
> reaction that would be given by a simplistic VM.  A simplistic solution may
> be faster in doing what it does, but in the real world time goes on from
> that point and what the VM did before effects what is happening later.  And
> overall a simplistic solution may actually hurt the performance of a VM.
>
A simplistic solution is more predictable, and therefor easier to write 
programs for that run well. This is the same principle that makes modern 
processors fast. We only need to enable any kind of program, not any 
behavior, becouse that behavior might in fact be harmfull or inefficient.

> People who use the latest 2.4.x kernel aren't running critical servers,
> rebooting back to their previous non-Rik vm kernel wont be much of an
> issue. It wont "break" anything, rather just be better or worse performance
> wise. If you can afford to reboot to upgrade to the latest 2.4.x, you can
> afford to reboot to move back to your backup kernel.
>
This sounds more like a pro-Andrea/Linus argument :)

`Allan

Re: VM

[Rik van Riel]

On Tue, 16 Oct 2001, Allan Sandfeld wrote:

> A simplistic solution is more predictable, and therefor easier to
> write programs for that run well.

Except for the gimp, I haven't seen any application which
actually takes the VM subsystem into account when doing
its things, so this balloon doesn't fly.

> This is the same principle that makes modern processors fast.
> We only need to enable any kind of program, not any behavior,
> becouse that behavior might in fact be harmfull or inefficient.

When comparing Linux 2.0 and Linux 2.2 you'll see that with
the simplistic solution in Linux 2.2 it is MUCH easier to
trigger bad behaviour than with Linux 2.0.

You'll also see that it is easier to make a robust VM fast
than to make a fast VM robust. The former is hard, the latter
is practically impossible.

I readily agree that the initial implementation of the VM
for Linux 2.4 had some bad things, but I'm not parting with
the idea that a VM should be designed to deal with strange
and heavy loads.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

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

Re: VM

[Patrick McFarland]

also considering more stuff, 
someone said that this is more of a political issue, but seeing that I stay out of political issues, Im looking for the better code here. Thats all I care about.

On 15-Oct-2001, Patrick McFarland wrote:
> reading what lang wrote, ive been thinking
> 
> Im on the type of machine that swapping the least is most favorable. rik's vm seems that it would be able to swap less, and not swap the wrong things enough of the time. andrea's, if i try to do something major, it swaps like crazy, but I havent tested rik's because I dont trust the rest of the ac tree to mess around with it. Is there any chance of rik's vm being atleast an option to choose, and possibly see what the community wants? Maybe if rik's vm is cleaned up, that 5% of stupidity would go down to the less than 1% we all hope for. 
> 
> On 16-Oct-2001, Linus Torvalds wrote:
> > In article <20011015211216.A1314@localhost>,
> > Patrick McFarland  <unknown@panax.com> wrote:
> > >
> > >Why is the simple vm system still in place on the linus tree? I would
> > think the smart vm system in the ac tree would be better suited to .. 
> > oh..  say ..  everything.
> > 
> > "complex" != "smart".
> > 
> > The benchmarks I've seen says that the simple VM performs better - both
> > in terms of repeatability and in terms of absolute performance. Search
> > this list yourself if you don't believe me.
> > 
> > 		Linus
> > -
> > 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/
> > 
> 
> -- 
> Patrick "Diablo-D3" McFarland || unknown@panax.com
> -
> 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/
> 

-- 
Patrick "Diablo-D3" McFarland || unknown@panax.com

Re: VM

[Stephan von Krawczynski]

On Mon, 15 Oct 2001 23:08:38 -0400 Patrick McFarland <unknown@panax.com> wrote:

> reading what lang wrote, ive been thinking
> 
> Im on the type of machine that swapping the least is most favorable. rik's vm
seems that it would be able to swap less, and not swap the wrong things enough
of the time.

Well, I cannot really comment on who does what based on the code. But I can see
the results on my machine(s). And what I see is that the current linus-tree
does not swap at all in my environment. Maybe one could say that 1 GB of RAM is
a bit oversized for most of my business, but anyway the point I started
complaining real loud about the former VM (now residing at -ac tree) was when
it came to the point where even my system started to become unusable. I am
therefore _very_ thankful to L. that he drew the line (who else could _and_
would have done it?), and Andrea of course for his work. I do not think that
Riks work is a piece of bs, really not, but it seems to have an inherent
complexity that is _very_ hard to handle. It may well be the proof for the
"keep it simple"-strategy to deliver the best results.
Anyway we should not see it as a political issue, but a friendly competition.
Because in the end, we all want the same: a system we can trust and rely on.
There is nothing wrong with having different opinions as long as you can give
_some_ proof for it. So if you say current -linus tree does more swapping,
please give us some numbers to have a look at.

Regards,
Stephan

Re: VM

[Andrea Arcangeli]

On Tue, Oct 16, 2001 at 12:26:27PM +0200, Stephan von Krawczynski wrote:
> On Mon, 15 Oct 2001 23:08:38 -0400 Patrick McFarland <unknown@panax.com> wrote:
> 
> > reading what lang wrote, ive been thinking
> > 
> > Im on the type of machine that swapping the least is most favorable. rik's vm
> seems that it would be able to swap less, and not swap the wrong things enough
> of the time.
> 
> Well, I cannot really comment on who does what based on the code. But I can see
> the results on my machine(s). And what I see is that the current linus-tree
> does not swap at all in my environment. Maybe one could say that 1 GB of RAM is

I was also surprised that mainline was swapping more, it shouldn't
really be the case. Infact in 2.4.13pre3aa1 I'm using shrink_cache to
probe when it's time to start paging, instead of waiting shrink_cache to
fail, this to avoid being too aggressive against the cache. So with
those recent changes it should start swapping earlier and it should swap
more.  But if it's now swapping too much it will be very easy to turn it
down the swap rate as worse with a few liner that removes such
cache-probe early-swap logic.

Andrea

Re: VM

[Rik van Riel]

On Wed, 17 Oct 2001, Andrea Arcangeli wrote:

> I was also surprised that mainline was swapping more, it shouldn't
> really be the case. Infact in 2.4.13pre3aa1 I'm using shrink_cache to
> probe when it's time to start paging, instead of waiting shrink_cache to
> fail, this to avoid being too aggressive against the cache. So with
> those recent changes it should start swapping earlier and it should swap
> more.  But if it's now swapping too much it will be very easy to turn it
> down the swap rate as worse with a few liner that removes such
> cache-probe early-swap logic.

This is exactly why I am so religious about page aging
on objects which are being used.  With just the referenced
bit you'll end up almost needing code tweaks to make the
system behave well under various different loads.

The VM just doesn't have the information it needs to
determine what to do...

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

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

Re: VM

[Andrea Arcangeli]

On Tue, Oct 16, 2001 at 10:49:28PM -0200, Rik van Riel wrote:
> The VM just doesn't have the information it needs to
> determine what to do...

additional page aging cannot make it different as far I can tell.
The twekaing I'm speaking about is a number. After probing the cache and
after getting many faliures I need to choose when it's time to start
the pagetable scanning. Additional bit of aging can only influence the number of
faliures, I cannot see how can it help to know when to start the
pagetable scanning. It's a _ratio_ between the faliures and the size of
the scan that tells me when it's the time. You need the same logic too
somewhere in -ac vm. Now if I turn the ratio very high the cache will
shrink more before we start pagetable scanning.  If I make it low we'll
swapout very easily. This ratio doesn't need to be perfect, it will
never trigger anyways most of the time, but it must be a sane number,
and it can make some difference during swapout.

Andrea

Re: VM

[Andrea Arcangeli]

On Mon, Oct 15, 2001 at 11:08:38PM -0400, Patrick McFarland wrote:
> reading what lang wrote, ive been thinking
> 
> Im on the type of machine that swapping the least is most favorable.
> rik's vm seems that it would be able to swap less, and not swap the
> wrong things enough of the time. andrea's, if i try to do something
> major, it swaps like crazy, but I havent tested rik's because I dont

strance if something it should swap less. It may look less responsive
under swap but that's mostly because we swap less and we drop more cache
instead.

Infact if you test 2.4.13pre3aa1 it should swap more and also be
more responsive under swap.

Andrea

Re: VM

[Anuradha Ratnaweera]

On Tue, Oct 16, 2001 at 01:57:41AM +0000, Linus Torvalds wrote:
>
> oh..  say ..  everything.
> 
> "complex" != "smart".

and almost always

    "simple" == "better"

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.12)

Absolutum obsoletum.  (If it works, it's out of date.)
		-- Stafford Beer

Re: VM

[Luigi Genoni]

I used bot VM in many situations and with many different HWs.
I came to the conclusion that  actually  none of the two VMs is suitable
for every use.
aa VM deals better because of its design on my web servers, with a non
eccessive amount of memory, and with mysql and oracle databases.

When I talk of AA vm i mean the 2.4.13preXaa1 versions.

Unfortunatelly I have also found a problem with
some situations when the VM is higly stressed, but Andrea was very kind to
this report, and now I hope it has gone away (will test this afternoon).

aa VM was also good with dualAthlon servers used for montecarlo
simulations, but also here, VM was not really stressed, and the system has
just 1 GB of RAM.

Rik VM in its later version is dealing better with Ultrasparc64
quadriprocessor with 4 GB RAM. But in this case we are talking of very
very stressed system, with hundreds of huge processes, doing a lot of swap
in/out, and with 8 GB swap space.
I am just sorry that i have access to this machine just from times to
times, when a critical problem appears, but this is a production server.

The reason is the aa VM is more predictable, but rik's one actually
seems to be smarter under very very stressed situations.

I do not care which VM is simpler, nor which is faster. I loock for
predictability, since this is the most important thing on the servers I am
administering. Under a special situation I need something maybe less
predictable, but smarter to manage a stressed system.

80%... 5%... I do not care for exact numbers actually, I will care in
future, if the situation comes to the point that both VMs will be quite
good for everything. anyway it is a good strategy to follow two different
way, since they are progressing quite welll together, with competition,
and also (I hope) reciprocal help (just to be able to read the code of the
other is a good help:) ).

Just now I am sorry I have to deal with this choice for every mission
critical server I have. I would like a single VM that is good for
everything, but I understand that this is the most difficoult thing to
reach, because the casistinc is going to be more and more complex, with
technology evolution, and
with time it will be even worse.


Luigi


On Tue, 16 Oct 2001, Anuradha Ratnaweera wrote:

> On Tue, Oct 16, 2001 at 01:57:41AM +0000, Linus Torvalds wrote:
> >
> > oh..  say ..  everything.
> >
> > "complex" != "smart".
>
> and almost always
>
>     "simple" == "better"
>
> Anuradha
>
> --
>
> Debian GNU/Linux (kernel 2.4.12)
>
> Absolutum obsoletum.  (If it works, it's out of date.)
> 		-- Stafford Beer
>
> -
> 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: VM

[bill davidsen]

In article <Pine.LNX.4.33.0110161503300.17096-100000@Expansa.sns.it> 
	kernel@Expansa.sns.it wrote:
>I used bot VM in many situations and with many different HWs.
>I came to the conclusion that  actually  none of the two VMs is suitable
>for every use.
>aa VM deals better because of its design on my web servers, with a non
>eccessive amount of memory, and with mysql and oracle databases.


>I do not care which VM is simpler, nor which is faster. I loock for
>predictability, since this is the most important thing on the servers I am
>administering. Under a special situation I need something maybe less
>predictable, but smarter to manage a stressed system.
>
>80%... 5%... I do not care for exact numbers actually, I will care in
>future, if the situation comes to the point that both VMs will be quite
>good for everything. anyway it is a good strategy to follow two different
>way, since they are progressing quite welll together, with competition,
>and also (I hope) reciprocal help (just to be able to read the code of the
>other is a good help:) ).

Very well said. And I might add that some input from people with small
desktop machines might be useful to the developers, since I doubt they
are running small slow machines. While I wouldn't compromise big memory
performance (much) for small, one beauty of Linux is that it will run
well on small machines.

Of course it may be that some other VM will prove to be bnetter than
either, but hopefully not until 2.5. I'd still like to see VM in a
module and then everyone could play with their pet theory;-)

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: VM

[Rik van Riel]

On Tue, 16 Oct 2001, Luigi Genoni wrote:

> The reason is the aa VM is more predictable, but rik's one actually
> seems to be smarter under very very stressed situations.

This is a different approach to the situation.  Most of the
time in the early 2.4 kernels we were much too busy to stop
machines from crashing to care about performance.

Only in more recent -ac kernels have I actually had time to
look at performance and it seems to be relatively easy to
get the VM to perform better.

Andrea seems to have optimised his VM for performance under
low to medium loads from the beginning ... but in Linux 2.2
we've seen how impossible it is to tune such a simplistic
VM to not fall apart under very high loads, so I won't be
going that way ;)

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/  (volunteers needed)

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

Re: VM

[Martin Dalecki]

Luigi Genoni wrote:
> 
> I used bot VM in many situations and with many different HWs.
> I came to the conclusion that  actually  none of the two VMs is suitable
> for every use.
> aa VM deals better because of its design on my web servers, with a non
> eccessive amount of memory, and with mysql and oracle databases.
> 
> When I talk of AA vm i mean the 2.4.13preXaa1 versions.
> 
> Unfortunatelly I have also found a problem with
> some situations when the VM is higly stressed, but Andrea was very kind to
> this report, and now I hope it has gone away (will test this afternoon).
> 
> aa VM was also good with dualAthlon servers used for montecarlo
> simulations, but also here, VM was not really stressed, and the system has
> just 1 GB of RAM.
> 
> Rik VM in its later version is dealing better with Ultrasparc64
> quadriprocessor with 4 GB RAM. But in this case we are talking of very
> very stressed system, with hundreds of huge processes, doing a lot of swap
> in/out, and with 8 GB swap space.
> I am just sorry that i have access to this machine just from times to
> times, when a critical problem appears, but this is a production server.
> 
> The reason is the aa VM is more predictable, but rik's one actually
> seems to be smarter under very very stressed situations.
> 
> I do not care which VM is simpler, nor which is faster. I loock for
> predictability, since this is the most important thing on the servers I am
> administering. Under a special situation I need something maybe less
> predictable, but smarter to manage a stressed system.

OK so let me bite now... If you look for predictability, then see:

Rik's page aging mechanism based VM went in short before 2.4.0 time.
Several months ago... Conceptually it was supposed to be a clone of
FreeBSD's memmory management system. However Rik overdesigned it
entierly. He inventen useless and far too many "tuning knobs".
And everybody should known that optimizations get really hard with
more then very few parameters. (Becouse even the math behind it get's
trully
complicated ;-) The situation until recently was
entierly inacceptable becouse the inadequacies of the VM where
blatant. No ORACLE running, no X session on lower memmory and so on and
so
on. Maybe by now he reached some level of stability, (by trail and error
if
you ask me), but please see that it only took 2 kernel release cycles 
until Andreas efforts showed fruits at least comparable (and in my
oppinnion much suprerior) to what can be currently seen in the ac series
in regard
of memmory management. This still holds even if you take into account
that Linus and AA both went a bit wild with the IO system redesign. 

Don't missunderstand me please I appreciate those changes as well
becouse
I see that they are finally addressing block device handling problems
I'm complaining about since 2 years regularly here and which are
artefact from the youngest days of Linux.

So if you look at this history and see what's going on the conculsion is
easly found: The chances are indeed very high that the behaviour of the
Linus tree is much more predictable ;-). (In the VM context of course.)

Re: VM

[Bill Davidsen]

In article <9qg46l$378$1@penguin.transmeta.com> torvalds@transmeta.com wrote:
>In article <20011015211216.A1314@localhost>,
>Patrick McFarland  <unknown@panax.com> wrote:
>>
>>Why is the simple vm system still in place on the linus tree? I would
>think the smart vm system in the ac tree would be better suited to .. 
>oh..  say ..  everything.
>
>"complex" != "smart".
>
>The benchmarks I've seen says that the simple VM performs better - both
>in terms of repeatability and in terms of absolute performance. Search
>this list yourself if you don't believe me.

  The problem may be one of perception. There has been a lot of effort
to fix large memory cases, and that's good. I have a load of 2-4GB
machines in remote locations with heavy load. I would like dead stable
and good performance, and that may be coming in either case.

  But for busy little machines, uni, small memory, which represent the
majority of desktops, I find the -ac VM seems to be significantly
faster in starting X, or netscape, or changing desktops. I haven't
tried 2.4.12, because I want to be sure to avoid another 2.4.11oh-shit
debacle. But at 2.4.10 the difference was significant, particularly on
small machines with slow disk. I'll try 2.4.12 Thursday unless major
bugs pop up and see how that does, 2.4.10-ac12 has been stable and
responsive, and I'm out of the office tomorrow and can't reboot if I
get an oops.

-- 
bill davidsen <davidsen@tmr.com>
 "If I were a diplomat, in the best case I'd go hungry.  In the worst
  case, people would die."
		-- Robert Lipe

Re: VM

[Alan Cox]

> Why is the simple vm system still in place on the linus tree? I would think 
> the smart vm system in the ac tree would be better suited to .. oh.. say ..
>  everything. (The potential for less swapping is _always better_)

I've not reached any final conclusions on the VM - there are things that
Rik's VM shows up that look like the VM algorithm is right but it triggers
other stuff, and there are a couple of hackish bits left in still.

Smart is often good - especially given how slow disk seeks are. But smart is
not always best for any algorithm.

Alan