Tech Insider					     Technology and Trends


			      USENET Archives

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Mon, 15 Oct 2001 21:12:18 -0400
From: Patrick McFarland <unkn...@panax.com>
To: linux-ker...@vger.kernel.org
Subject: VM
Original-Message-ID: <20011015211216.A1314@localhost>
Mail-Followup-To: linux-ker...@vger.kernel.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.22i
X-Operating-System: Linux 2.4.12 i586
X-Distributed: Join the Effort!  http://www.distributed.net/
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 01:14:16 GMT
Message-ID: <fa.emrqgiv.1h14ro0@ifi.uio.no>
Lines: 11

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 || unkn...@panax.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
logbridge.uoregon.edu!news.tele.dk!small.news.tele.dk!129.240.148.23!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: palladium.transmeta.com: 
mail set sender to n...@transmeta.com using -f
To: linux-ker...@vger.kernel.org
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: VM
Original-Date: 	Tue, 16 Oct 2001 01:57:41 +0000 (UTC)
Original-Message-ID: <9qg46l$378$1@penguin.transmeta.com>
Original-References: <20011015211216.A1314@localhost>
X-Complaints-To: news@transmeta.com
Original-NNTP-Posting-Date: 16 Oct 2001 01:58:06 GMT
Cache-Post-Path: palladium.transmeta.com!unkn...@penguin.transmeta.com
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Date: Tue, 16 Oct 2001 02:00:18 GMT
Message-ID: <fa.ho2e18v.12ni78u@ifi.uio.no>
References: <fa.emrqgiv.1h14ro0@ifi.uio.no>
Lines: 19

In article <20011015211216.A1314@localhost>,
Patrick McFarland  <unkn...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Mon, 15 Oct 2001 23:08:38 -0400
From: Patrick McFarland <unkn...@panax.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011015230836.B1314@localhost>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
	linux-ker...@vger.kernel.org
Original-References: 
<20011015211216.A1314@localhost> <9qg46l$37...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9qg46l$378$1@penguin.transmeta.com>
User-Agent: Mutt/1.3.22i
X-Operating-System: Linux 2.4.12 i586
X-Distributed: Join the Effort!  http://www.distributed.net/
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 03:10:05 GMT
Message-ID: <fa.enrugav.1g10rg9@ifi.uio.no>
References: <fa.ho2e18v.12ni78u@ifi.uio.no>
Lines: 33

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  <unkn...@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 majord...@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 || unkn...@panax.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: VM
To: unkn...@panax.com (Patrick McFarland)
Original-Date: 	Tue, 16 Oct 2001 09:08:40 +0100 (BST)
Cc: linux-ker...@vger.kernel.org
In-Reply-To: <20011015211216.A1314@localhost> 
from "Patrick McFarland" at Oct 15, 2001 09:12:18 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E15tPHE-0004zS-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 08:05:25 GMT
Message-ID: <fa.h118s8v.1h5kiov@ifi.uio.no>
References: <fa.emrqgiv.1h14ro0@ifi.uio.no>
Lines: 17

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 14:14:29 +0600
From: Anuradha Ratnaweera <anura...@gnu.org>
To: Linus Torvalds <torva...@transmeta.com>
Cc: linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011016141429.A29907@bee.lk>
Original-References: <20011015211216.A1314@localhost> 
<9qg46l$37...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9qg46l$378$1@penguin.transmeta.com>; 
from torvalds@transmeta.com on Tue, Oct 16, 2001 at 01:57:41AM +0000
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 08:16:42 GMT
Message-ID: <fa.c6u4qav.jhaa0u@ifi.uio.no>
References: <fa.ho2e18v.12ni78u@ifi.uio.no>
Lines: 24

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 12:26:27 +0200
From: Stephan von Krawczynski <sk...@ithnet.com>
To: Patrick McFarland <unkn...@panax.com>
Cc: linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-Id: <20011016122627.110964ec.skraw@ithnet.com>
In-Reply-To: <20011015230836.B1314@localhost>
Original-References: <20011015211216.A1314@localhost>
	<9qg46l$37...@penguin.transmeta.com>
	<20011015230836.B1314@localhost>
X-Mailer: Sylpheed version 0.6.3 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: ith Kommunikationstechnik GmbH
Date: Tue, 16 Oct 2001 10:28:27 GMT
Message-ID: <fa.gj4jbqv.3ilq6@ifi.uio.no>
References: <fa.enrugav.1g10rg9@ifi.uio.no>
Lines: 33

On Mon, 15 Oct 2001 23:08:38 -0400 Patrick McFarland <unkn...@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

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 15:36:13 +0200 (CEST)
From: Luigi Genoni <ker...@Expansa.sns.it>
To: Anuradha Ratnaweera <anura...@gnu.org>
cc: Linus Torvalds <torva...@transmeta.com>, <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <20011016141429.A29907@bee.lk>
Original-Message-ID: <Pine.LNX.4.33.0110161503300.17096-100000@Expansa.sns.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 13:38:30 GMT
Message-ID: <fa.hs770gv.4h0v88@ifi.uio.no>
References: <fa.c6u4qav.jhaa0u@ifi.uio.no>
Lines: 82

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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news1.ebone.net!news.ebone.net!
news.net.uni-c.dk!uninett.no!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 12:11:30 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@imladris.surriel.com>
To: Luigi Genoni <ker...@Expansa.sns.it>
Cc: Anuradha Ratnaweera <anura...@gnu.org>,
        Linus Torvalds <torva...@transmeta.com>,
        <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <Pine.LNX.4.33.0110161503300.17096-100000@Expansa.sns.it>
Original-Message-ID: <Pine.LNX.4.33L.0110161205380.6440-100000@imladris.surriel.com>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 14:13:25 GMT
Message-ID: <fa.ngn9lgv.67q1i0@ifi.uio.no>
References: <fa.hs770gv.4h0v88@ifi.uio.no>
Lines: 32

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/

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

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed1.cidera.com!Cidera!news2.dg.net.ua!
bn.utel.com.ua!carrier.kiev.ua!not-for-mail
From: safemode <safem...@speakeasy.net>
Newsgroups: lucky.linux.kernel
Subject: Re: VM
Date: Tue, 16 Oct 2001 05:11:33 +0000 (UTC)
Organization: unknown
Lines: 64
Sender: n...@solar.carrier.kiev.ua
Approved: newsmas...@lucky.net
Message-ID: <20011016050739Z278091-17409+653@vger.kernel.org>
References: <20011015211216.A1314@localhost> 
<20011015232245.F1314@localhost> <1003202891.863.1.camel@phantasy>
NNTP-Posting-Host: solar.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: solar.carrier.kiev.ua 1003209094 4335 193.193.193.118 (16 Oct 2001 05:11:34 GMT)
X-Complaints-To: usenet@solar.carrier.kiev.ua
NNTP-Posting-Date: Tue, 16 Oct 2001 05:11:34 +0000 (UTC)
X-Mailer: KMail [version 1.3.2]
In-Reply-To: <1003202891.863.1.camel@phantasy>
X-Mailing-List: 	linux-kernel@vger.kernel.org

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 majord...@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

From: David Lang (dlang@diginsite.com)
Date: Mon Oct 15 2001 - 23:40:11 EST

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/
>
-
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/


Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed1.cidera.com!Cidera!news2.dg.net.ua!
bn.utel.com.ua!carrier.kiev.ua!not-for-mail
From: safemode <safem...@speakeasy.net>
Newsgroups: lucky.linux.kernel
Subject: Re: VM
Date: Tue, 16 Oct 2001 13:37:16 +0000 (UTC)
Organization: unknown
Lines: 196
Sender: n...@solar.carrier.kiev.ua
Approved: newsmas...@lucky.net
Message-ID: <20011016133402Z276231-17408+990@vger.kernel.org>
References: <Pine.LNX.4.40.0110152111280.1380-100000@dlang.diginsite.com>
NNTP-Posting-Host: solar.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: solar.carrier.kiev.ua 1003239436 14275 193.193.193.118 (16 Oct 2001 13:37:16 GMT)
X-Complaints-To: usenet@solar.carrier.kiev.ua
NNTP-Posting-Date: Tue, 16 Oct 2001 13:37:16 +0000 (UTC)
X-Mailer: KMail [version 1.3.2]
In-Reply-To: <Pine.LNX.4.40.0110152111280.1380-100000@dlang.diginsite.com>
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: David Lang

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 <safem...@speakeasy.net>
> > To: linux-ker...@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 majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

From: Allan Sandfeld (linux@sneulv.dk)
Date: Tue Oct 16 2001 - 09:19:37 EST

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
-
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

From: David Lang (david.lang@digitalinsight.com)
Date: Tue Oct 16 2001 - 11:44:24 EST

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.
>
-
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/


Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 14:14:41 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@imladris.surriel.com>
To: Allan Sandfeld <li...@sneulv.dk>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <E15tV4X-0000PN-00@Princess>
Original-Message-ID: <Pine.LNX.4.33L.0110161406550.6440-100000@imladris.surriel.com>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 16:17:26 GMT
Message-ID: <fa.nh7dl8v.7nm3a0@ifi.uio.no>
References: <fa.f4nm5qv.1c78101@ifi.uio.no>
Lines: 39

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/

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 16:11:44 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@imladris.surriel.com>
To: David Lang <david.l...@digitalinsight.com>
Cc: safemode <safem...@speakeasy.net>, <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <Pine.LNX.4.40.0110160932370.6108-100000@dlang.diginsite.com>
Original-Message-ID: <Pine.LNX.4.33L.0110161610170.6440-100000@imladris.surriel.com>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 18:15:23 GMT
Message-ID: <fa.ne75m8v.4nu3a1@ifi.uio.no>
References: <fa.lot7f2v.1c003a7@ifi.uio.no>
Lines: 27

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/

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Wed, 17 Oct 2001 01:24:07 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Patrick McFarland <unkn...@panax.com>
Cc: Linus Torvalds <torva...@transmeta.com>, linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011017012407.Q2380@athlon.random>
Original-References: <20011015211216.A1314@localhost> 
<9qg46l$37...@penguin.transmeta.com> <20011015230836.B1314@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <20011015230836.B1314@localhost>; 
from unknown@panax.com on Mon, Oct 15, 2001 at 11:08:38PM -0400
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 23:26:00 GMT
Message-ID: <fa.gih1gsv.ma5hu@ifi.uio.no>
References: <fa.enrugav.1g10rg9@ifi.uio.no>
Lines: 21

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Wed, 17 Oct 2001 01:38:56 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Stephan von Krawczynski <sk...@ithnet.com>
Cc: Patrick McFarland <unkn...@panax.com>, linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011017013856.R2380@athlon.random>
Original-References: <20011015211216.A1314@localhost> 
<9qg46l$37...@penguin.transmeta.com> <20011015230836.B1314@localhost> 
<20011016122627.110964ec.sk...@ithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <20011016122627.110964ec.skraw@ithnet.com>; 
from skraw@ithnet.com on Tue, Oct 16, 2001 at 12:26:27PM +0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 16 Oct 2001 23:41:05 GMT
Message-ID: <fa.gl0vh4v.2685ph@ifi.uio.no>
References: <fa.gj4jbqv.3ilq6@ifi.uio.no>
Lines: 28

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 <unkn...@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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 16 Oct 2001 22:49:28 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@imladris.surriel.com>
To: Andrea Arcangeli <and...@suse.de>
Cc: Stephan von Krawczynski <sk...@ithnet.com>,
        Patrick McFarland <unkn...@panax.com>, <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <20011017013856.R2380@athlon.random>
Original-Message-ID: <Pine.LNX.4.33L.0110162247210.6440-100000@imladris.surriel.com>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 17 Oct 2001 00:51:11 GMT
Message-ID: <fa.nhn9jov.77u3q4@ifi.uio.no>
References: <fa.gl0vh4v.2685ph@ifi.uio.no>
Lines: 32

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/

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Wed, 17 Oct 2001 03:15:42 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Rik van Riel <r...@conectiva.com.br>
Cc: Stephan von Krawczynski <sk...@ithnet.com>,
        Patrick McFarland <unkn...@panax.com>, linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011017031542.X2380@athlon.random>
Original-References: <20011017013856.R2...@athlon.random> 
<Pine.LNX.4.33L.0110162247210.6440-100...@imladris.surriel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <Pine.LNX.4.33L.0110162247210.6440-100000@imladris.surriel.com>; 
from riel@conectiva.com.br on Tue, Oct 16, 2001 at 10:49:28PM -0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 17 Oct 2001 01:17:27 GMT
Message-ID: <fa.gkgrgkv.2m459m@ifi.uio.no>
References: <fa.nhn9jov.77u3q4@ifi.uio.no>
Lines: 23

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Message-ID: <3BD420ED.4090508@fibrespeed.net>
Original-Date: 	Mon, 22 Oct 2001 09:36:45 -0400
From: "Michael T. Babcock" <mbabc...@fibrespeed.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
X-Accept-Language: en-us
MIME-Version: 1.0
To: Linux Kernel <linux-ker...@vger.kernel.org>
Subject: Re: VM
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: CyTech Computers
Date: Mon, 22 Oct 2001 13:38:21 GMT
Message-ID: <fa.erh653v.1kn2m8a@ifi.uio.no>
Lines: 22

 > 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


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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: VM
To: mbabc...@fibrespeed.net (Michael T. Babcock)
Original-Date: 	Mon, 22 Oct 2001 15:02:49 +0100 (BST)
Cc: linux-ker...@vger.kernel.org (Linux Kernel)
In-Reply-To: <3BD420ED.4090508@fibrespeed.net> 
from "Michael T. Babcock" at Oct 22, 2001 09:36:45 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E15vffF-00023N-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 22 Oct 2001 13:58:05 GMT
Message-ID: <fa.g8iqsgv.emii0r@ifi.uio.no>
References: <fa.erh653v.1kn2m8a@ifi.uio.no>
Lines: 11

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Mon, 22 Oct 2001 11:00:58 -0700
From: Mike Fedyk <mfe...@matchmail.com>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: "Michael T. Babcock" <mbabc...@fibrespeed.net>,
        Linux Kernel <linux-ker...@vger.kernel.org>
Subject: Re: VM
Original-Message-ID: <20011022110058.C27227@mikef-linux.matchmail.com>
Mail-Followup-To: Alan Cox <a...@lxorguk.ukuu.org.uk>,
	"Michael T. Babcock" <mbabc...@fibrespeed.net>,
	Linux Kernel <linux-ker...@vger.kernel.org>
Original-References: <3BD420ED.4090...@fibrespeed.net> 
<E15vffF-00023N...@the-village.bc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E15vffF-00023N-00@the-village.bc.nu>
User-Agent: Mutt/1.3.23i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 22 Oct 2001 18:05:29 GMT
Message-ID: <fa.kkhmmcv.123g78m@ifi.uio.no>
References: <fa.g8iqsgv.emii0r@ifi.uio.no>
Lines: 15

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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!148.122.208.68!news2.oke.nextra.no!
nextra.com!uninett.no!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Mon, 22 Oct 2001 15:32:41 -0200 (BRST)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Mike Fedyk <mfe...@matchmail.com>
Cc: Alan Cox <a...@lxorguk.ukuu.org.uk>,
        "Michael T. Babcock" <mbabc...@fibrespeed.net>,
        Linux Kernel <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <20011022110058.C27227@mikef-linux.matchmail.com>
Original-Message-ID: 
<Pine.LNX.4.21.0110221531290.15815-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 22 Oct 2001 18:56:07 GMT
Message-ID: <fa.n43hv6v.46ib8d@ifi.uio.no>
References: <fa.kkhmmcv.123g78m@ifi.uio.no>
Lines: 23


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. 

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

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: VM
To: mfe...@matchmail.com (Mike Fedyk)
Original-Date: 	Mon, 22 Oct 2001 21:21:03 +0100 (BST)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox),
        mbabc...@fibrespeed.net (Michael T. Babcock),
        linux-ker...@vger.kernel.org (Linux Kernel)
In-Reply-To: <20011022110058.C27227@mikef-linux.matchmail.com> 
from "Mike Fedyk" at Oct 22, 2001 11:00:58 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E15vlZH-0003D3-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Mon, 22 Oct 2001 20:17:15 GMT
Message-ID: <fa.gk0ct0v.1g2ghgq@ifi.uio.no>
References: <fa.kkhmmcv.123g78m@ifi.uio.no>
Lines: 12

> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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

From: Marcelo Roberto Jimenez (mroberto@cetuc.puc-rio.br)
Date: Mon Oct 22 2001 - 16:33:16 EST

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.
 

-
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

From: Oliver Xymoron (oxymoron@waste.org)
Date: Mon Oct 22 2001 - 16:44:14 EST

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/


Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 23 Oct 2001 00:27:04 -0400
From: Patrick McFarland <unkn...@panax.com>
To: Oliver Xymoron <oxymo...@waste.org>
Cc: linux-ker...@vger.kernel.org
Subject: Re: VM
Original-Message-ID: <20011023002702.A2446@localhost>
Mail-Followup-To: Oliver Xymoron <oxymo...@waste.org>,
	linux-ker...@vger.kernel.org
Original-References: 
<3032.139.82.28.36.1003786396.squir...@mamona.cetuc.puc-rio.br> 
<Pine.LNX.4.30.0110221640310.8629-100...@waste.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.30.0110221640310.8629-100000@waste.org>
User-Agent: Mutt/1.3.23i
X-Operating-System: Linux 2.4.12 i586
X-Distributed: Join the Effort!  http://www.distributed.net/
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 23 Oct 2001 04:29:58 GMT
Message-ID: <fa.elrihqv.1h10qg1@ifi.uio.no>
References: <fa.j0kv4uv.18jeqat@ifi.uio.no>
Lines: 40

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 majord...@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 || unkn...@panax.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!195.158.233.21!news1.ebone.net!
news.ebone.net!news.net.uni-c.dk!uninett.no!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
To: linux-ker...@vger.kernel.org
Original-Path: 	not-for-mail
Original-Newsgroups: linux.dev.kernel
Subject: Re: VM
Original-References: <20011023002702.A2446@localhost>
From: david...@tmr.com (bill davidsen)
X-Newsreader: trn 4.0-test75 (Feb 13, 2001)
Originator: david...@deathstar.prodigy.com (Bill Davidsen)
Lines: 	34
Original-Message-ID: <63kB7.3873$0w5.657641665@newssvr17.news.prodigy.com>
Original-NNTP-Posting-Host: 192.168.192.240
X-Complaints-To: abuse@prodigy.net
Original-NNTP-Posting-Date: Tue, 23 Oct 2001 16:04:18 EDT
Original-Date: 	Tue, 23 Oct 2001 20:04:18 GMT
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: TMR Associates, Schenectady NY
Date: Tue, 23 Oct 2001 20:05:50 GMT
Message-ID: <fa.lrb39ev.bjod9l@ifi.uio.no>
References: <fa.elrihqv.1h10qg1@ifi.uio.no>

In article <20011023002702.A2446@localhost>,
Patrick McFarland <unkn...@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 <david...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Tue, 23 Oct 2001 18:13:59 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@imladris.surriel.com>
To: bill davidsen <david...@tmr.com>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: VM
In-Reply-To: <63kB7.3873$0w5.657641665@newssvr17.news.prodigy.com>
Original-Message-ID: 
<Pine.LNX.4.33L.0110231813490.3690-100000@imladris.surriel.com>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 23 Oct 2001 20:18:57 GMT
Message-ID: <fa.ne75nov.7nu3qf@ifi.uio.no>
References: <fa.lrb39ev.bjod9l@ifi.uio.no>
Lines: 19

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/

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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/