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