Message-ID: <3C08057D.48645B56@zip.com.au>
Date: Fri, 30 Nov 2001 23:30:11 +0100
From: Andrew Morton <a...@zip.com.au>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-pre1 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Coding style - a non-issue
References: <OF8451D8AC.A8591425-ON4A256B12.00806245@au.ibm.com>
<E169scn-0000kt-00@starship.berlin> <20011130110546.V14710@work.bitmover.com>
<E169vcF-0000lQ-00@starship.berlin>,
<E169vcF-0000lQ-00@starship.berlin>; from phillips@bonn-fries.net
on Fri, Nov 30, 2001 at 10:54:39PM +0100 <20011130140613.F14710@work.bitmover.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.455.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!
t-online.de!bofh.it!robomod
X-Original-Cc: Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
X-Original-Date: Fri, 30 Nov 2001 14:17:33 -0800
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Larry McVoy <l...@bitmover.com>
Lines: 14
Larry McVoy wrote:
>
> Linux isn't there yet
> and unless the development model changes somewhat, I'll stand behind my
> belief that it is unlikely to ever get there.
I am (genuinely) interested in what changes you think are needed.
-
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Fri, 30 Nov 2001 15:57:40 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Andrew Morton <a...@zip.com.au>
X-Cc: Larry McVoy <l...@bitmover.com>, Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011130155740.I14710@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 133
On Fri, Nov 30, 2001 at 02:17:33PM -0800, Andrew Morton wrote:
> Larry McVoy wrote:
> >
> > Linux isn't there yet
> > and unless the development model changes somewhat, I'll stand behind my
> > belief that it is unlikely to ever get there.
>
> I am (genuinely) interested in what changes you think are needed.
Well I have an opinion, not sure if it will be well received or not,
but here goes.
There is a choice which needs to be made up front, and that is this:
do you want to try and turn the Linux kernel hackers into Sun style
hackers or do you want to try something else?
This assumes we have agreement that there is a difference between the
two camps. I'd rather not get into a "this way is better than that way"
discussion, let's just postulate that the Sun way has some pros/cons
and so do the Linux way.
If you want to try and make Linux people work like Sun people, I think
that's going to be tough. First of all, Sun has a pretty small kernel
group, they work closely with each other, and they are full time,
highly paid, professionals working with a culture that is intolerant of
anything but the best. It's a cool place to be, to learn, but I think
it is virtually impossible to replicate in a distributed team, with way
more people, who are not paid the same or working in the same way.
Again, let's not argue the point, let's postulate for the time being
that the Linux guys aren't going to work like the Sun guys any time soon.
So what's the problem? The Sun guys fix more bugs, handle more corner
cases, and scale up better (Linux is still better on the uniprocessors
but the gap has narrowed considerably; Sun is getting better faster than
Linux is getting better, performance wise. That's a bit unfair because
Linux had, and has, better absolute numbers so there was less room to
improve, but the point is that Sun is catching up fast.)
As the source base increases in size, handles more devices, runs on more
platforms, etc., it gets harder and harder to make the OS be reliable.
Anyone can make a small amount of code work well, it's exponentially
more difficult to make a large amount of code work well. There are lots
of studies which show this to be true, the mythical man month is a good
starting place.
OK, so it sounds like I'm saying that the Linux guys are lame, Sun is
great, and there isn't any chance that Linux is going to be as good
as Solaris. That's not quite what I'm saying. *If* you want to play
by the same rules as Sun, i.e., develop and build things the same way,
then that is what I'm saying. The Linux team will never be as good
as the Sun team unless the Sun team gets a lot worse. I think that's
a fact of life, Sun has 100s of millions of dollars a year going into
software development. ESR can spout off all he likes, but there is no
way a team of people working for fun is going to compete with that.
On the other hand, there is perhaps a way Linux could be better. But it
requires changing the rules quite a bit.
Instead of trying to make the Linux hackers compete with the Sun hackers,
what would happen if you architected your way around the problem?
For example, suppose I said we need to have a smaller, faster, more
reliable uniprocessor kernel. Suppose I could wave a magic wand and
make SMP go away (I can't, but bear with me for a second). The problem
space just got at least an order of magnitude less complex than what Sun
deals with. I think they are up to 32-64 way SMP and you can imagine,
I hope, the additional complexity that added. OK, so *if* uniprocessor
was the only thing we had to worry about, or say 2-4 way SMP with just
a handful of locks, then can we agree that it is a lot more likely that
we could produce a kernel which was in every way as good or better than
Sun's kernel, on the same platform? If the answer is yes, keep reading,
if the answer is no, then we're done because I don't know what to do if
we can't get that far.
For the sake of discussion, let's assume that you buy what I am saying
so far. And let's say that we agree that if you were to toss the SMP
stuff then we have a good chance at making a reliable kernel, albeit
an uninteresting one when compared to big boxes. If you want me to go
into what I think it would take to do that, I will.
The problem is that we can't ignore the SMP issues, it drives hardware
sales, gets press, it's cool, etc. We have to have both but the problem
is that if we have both we really need Sun's level of professionalism
to make it work, and it isn't realistic to expect that from a bunch of
underpaid (or not at all paid) Linux hackers.
Here's how you get both. Fork the development efforts into the SMP part
and the uniprocessor part. The uniprocessor focus is on reliability,
stability, performance. The SMP part is a whole new development effort,
which is architected in such a way as to avoid the complexity of a
traditional SMP implementation.
The uniprocessor team owns the core architecture of the system. The
abstractions provided, the baseline code, etc., that's all uni. The
focus there is a small, fast, stable kernel.
The SMP team doesn't get to touch the core code, or at least there is
a very strong feedback loop against. In private converstations, we've
started talking about the "punch in the nose" feedback loop, which means
while it may be necessary to touch generic code for the benefit of SMP,
someone has to feel strongly enough about it that they well sacrifice
their nose.
It would seem like I haven't solved anything here, just painted a nice
but impossible picture. Maybe. I've actually thought long and hard
about the approach needed to scale up without touching all the code
and it is radically different from the traditional way (i.e., how
Sun, SGI, Sequent, etc., did it). If you are interested in that, I'll
talk about it but I'll wait to see if anyone cares.
The summary over all of this is:
If you want to solve all the problems that Sun does, run on the same
range of UP to big SMP, Linux is never going to be as reliable as
Solaris. My opinion, of course, but one that is starting to gain
some traction as the OS becomes more complex.
That leaves you with a choice: either give up on some things,
magically turn the Linux hackers into Sun hackers, or
architect your way around the problem.
My vote is the last one, it fits better with the Linux effort, the answer
is way more cool than anything Sun or anyone else has done, and it lets
you have a simple mainline kernel source base.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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: Fri, 30 Nov 2001 22:35:33 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.surriel.com>
To: Andrew Morton <a...@zip.com.au>
Cc: Larry McVoy <l...@bitmover.com>, Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>,
Linus Torvalds <torva...@transmeta.com>,
<linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <3C08057D.48645B56@zip.com.au>
Original-Message-ID: <Pine.LNX.4.33L.0111302234420.4079-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: Sat, 1 Dec 2001 00:37:23 GMT
Message-ID: <fa.nhn9j8v.17m2a2@ifi.uio.no>
References: <fa.d8ungdv.1qng12u@ifi.uio.no>
Lines: 23
On Fri, 30 Nov 2001, Andrew Morton wrote:
> Larry McVoy wrote:
> > Linux isn't there yet
> > and unless the development model changes somewhat, I'll stand behind my
> > belief that it is unlikely to ever get there.
>
> I am (genuinely) interested in what changes you think are needed.
I'm very interested too, though I'll have to agree with Larry
that Linux really isn't going anywhere in particular and seems
to be making progress through sheer luck.
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Fri, 30 Nov 2001 16:50:34 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: Andrew Morton <a...@zip.com.au>, Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <Pine.LNX.4.33L.0111302234420.4079-100000@imladris.surriel.com>
Original-Message-ID: <Pine.LNX.4.33.0111301643170.1224-100000@penguin.transmeta.com>
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: Sat, 1 Dec 2001 00:58:03 GMT
Message-ID: <fa.o9pve6v.h4c4rb@ifi.uio.no>
References: <fa.nhn9j8v.17m2a2@ifi.uio.no>
Lines: 49
On Fri, 30 Nov 2001, Rik van Riel wrote:
>
> I'm very interested too, though I'll have to agree with Larry
> that Linux really isn't going anywhere in particular and seems
> to be making progress through sheer luck.
Hey, that's not a bug, that's a FEATURE!
You know what the most complex piece of engineering known to man in the
whole solar system is?
Guess what - it's not Linux, it's not Solaris, and it's not your car.
It's you. And me.
And think about how you and me actually came about - not through any
complex design.
Right. "sheer luck".
Well, sheer luck, AND:
- free availability and _crosspollination_ through sharing of "source
code", although biologists call it DNA.
- a rather unforgiving user environment, that happily replaces bad
versions of us with better working versions and thus culls the herd
(biologists often call this "survival of the fittest")
- massive undirected parallel development ("trial and error")
I'm deadly serious: we humans have _never_ been able to replicate
something more complicated than what we ourselves are, yet natural
selection did it without even thinking.
Don't underestimate the power of survival of the fittest.
And don't EVER make the mistake that you can design something better than
what you get from ruthless massively parallel trial-and-error with a
feedback cycle. That's giving your intelligence _much_ too much credit.
Quite frankly, Sun is doomed. And it has nothing to do with their
engineering practices or their coding style.
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!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Fri, 30 Nov 2001 17:13:38 -0800 (PST)
From: Davide Libenzi <davi...@xmailserver.org>
X-To: Larry McVoy <l...@bitmover.com>
X-cc: Andrew Morton <a...@zip.com.au>, Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.Pine.LNX.4.40.0111301636010.1600-100000@blue1.dev.mcafeelabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 54
On Fri, 30 Nov 2001, Larry McVoy wrote:
[ A lot of stuff Pro-Sun ]
Wait a minute.
Wasn't it you that were screaming against Sun, leaving their team because
their SMP decisions about scaling sucked, because their OS was bloated
like hell with sync spinlocks, saying that they tried to make it scale but
they failed miserably ?
What is changed now to make Solaris, a fairly vanishing OS, to be the
reference OS/devmodel for every kernel developer ?
Wasn't it you that were saying that Linux will never scale with more than
2 CPUs ?
Isn't Linux SMP improved from the very first implementation ?
Isn't Linux SMP improved from the very first implementation w/out losing
reliability ?
Why you don't try to compare 2.0.36 with 2.4.x let's say on a 8 way SMP ?
Why should it stop improving ?
Because you know that adding fine grained spinlocks will make the OS
complex to maintain and bloated ... like it was Solaris before you
suddendly changed your mind.
<YOUR QUOTE>
> Then people want more performance. So they thread some more and now
> the locks aren't 1:1 to the objects. What a lock covers starts to
> become fuzzy. Thinks break down quickly after this because what
> happens is that it becomes unclear if you are covered or not and
> it's too much work to figure it out, so each time a thing is added
> to the kernel, it comes with a lock. Before long, your 10 or 20
> locks are 3000 or more like what Solaris has. This is really bad,
> it hurts performance in far reaching ways and it is impossible to
> undo.
</YOUR QUOTE>
I kindly agree with this, just curious to understand which kind of amazing
architectural solution Solaris took to be a reference for SMP
development/scaling.
- Davide
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Fri, 30 Nov 2001 17:15:10 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Davide Libenzi <davi...@xmailserver.org>
X-Cc: Larry McVoy <l...@bitmover.com>, Andrew Morton <a...@zip.com.au>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011130171510.B19152@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 64
On Fri, Nov 30, 2001 at 05:13:38PM -0800, Davide Libenzi wrote:
> On Fri, 30 Nov 2001, Larry McVoy wrote:
> Wait a minute.
> Wasn't it you that were screaming against Sun, leaving their team because
> their SMP decisions about scaling sucked, because their OS was bloated
> like hell with sync spinlocks, saying that they tried to make it scale but
> they failed miserably ?
Yup, that's me, guilty on all charges.
> What is changed now to make Solaris, a fairly vanishing OS, to be the
> reference OS/devmodel for every kernel developer ?
It's not. I never said that we should solve the same problems the same
way that Sun did, go back and read the posting.
> Wasn't it you that were saying that Linux will never scale with more than
> 2 CPUs ?
No, that wasn't me. I said it shouldn't scale beyond 4 cpus. I'd be pretty
lame if I said it couldn't scale with more than 2. Should != could.
> Because you know that adding fine grained spinlocks will make the OS
> complex to maintain and bloated ... like it was Solaris before you
> suddendly changed your mind.
Sorry it came out like that, I haven't changed my mind one bit.
> <YOUR QUOTE>
> > Then people want more performance. So they thread some more and now
> > the locks aren't 1:1 to the objects. What a lock covers starts to
> > become fuzzy. Thinks break down quickly after this because what
> > happens is that it becomes unclear if you are covered or not and
> > it's too much work to figure it out, so each time a thing is added
> > to the kernel, it comes with a lock. Before long, your 10 or 20
> > locks are 3000 or more like what Solaris has. This is really bad,
> > it hurts performance in far reaching ways and it is impossible to
> > undo.
> </YOUR QUOTE>
>
> I kindly agree with this, just curious to understand which kind of amazing
> architectural solution Solaris took to be a reference for SMP
> development/scaling.
OK, so you got the wrong message. I do _not_ like the approach Sun took,
it's a minor miracle that they are able to make Solaris work as well as
it works given the design decisions they made.
What I do like is Sun's engineering culture. They work hard, they don't
back away from the corner cases, they have high standards. All of which
and more are, in my opinion, a requirement to try and solve the problems
the way they solved them.
So the problem I've been stewing on is how you go about scaling the OS
in a way that doesn't require all those hot shot sun engineers to make
it work and maintain it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Message-ID: <linux.kernel.3C082FEB.98D8BE9B@zip.com.au>
Date: Fri, 30 Nov 2001 17:18:35 -0800
From: Andrew Morton <a...@zip.com.au>
MIME-Version: 1.0
X-To: Davide Libenzi <davi...@xmailserver.org>
X-CC: Larry McVoy <l...@bitmover.com>, Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 33
Davide Libenzi wrote:
>
> On Fri, 30 Nov 2001, Larry McVoy wrote:
>
> [ A lot of stuff Pro-Sun ]
>
> Wait a minute.
umm.. Let's try to keep moving forward here.
Larry appears to be referring to the proposal sometimes
known as ccClusters. I'd ask him a couple of followup questions:
Is there any precedent for the ccCluster idea, which would
increase confidence that it'll actually work?
Will it run well on existing hardware, or are changes needed?
You're assuming that our current development processes are
sufficient for development of a great 1-to-4-way kernel, and
that the biggest force against that is the introduction of
fine-grained locking. Are you sure about this? Do you see
ways in which the uniprocessor team can improve?
My take is that there's a sort of centralism in the kernel where
key people get atracted into mm/*.c, fs/*.c, net/most_everything
and kernel/*.c while other great wilderness of the tree (with
honourable exceptions) get moldier. How to address that?
-
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!fu-berlin.de!
news-feed.ifi.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
From: Tim Hockin <thoc...@hockin.org>
Original-Message-Id: <200112010202.fB122bE20177@www.hockin.org>
Subject: Re: Coding style - a non-issue
To: torva...@transmeta.com (Linus Torvalds)
Original-Date: Fri, 30 Nov 2001 18:02:37 -0800 (PST)
Cc: r...@conectiva.com.br (Rik van Riel), a...@zip.com.au (Andrew Morton),
l...@bitmover.com (Larry McVoy),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
In-Reply-To: <Pine.LNX.4.33.0111301643170.1224-100000@penguin.transmeta.com>
from "Linus Torvalds" at Nov 30, 2001 04:50:34 PM
X-Mailer: ELM [version 2.5 PL3]
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: Internet mailing list
Date: Sat, 1 Dec 2001 02:29:03 GMT
Message-ID: <fa.ffh7gjv.1bn291i@ifi.uio.no>
References: <fa.o9pve6v.h4c4rb@ifi.uio.no>
Lines: 18
> I'm deadly serious: we humans have _never_ been able to replicate
> something more complicated than what we ourselves are, yet natural
> selection did it without even thinking.
a very interesting argument, but not very pertinent - we don't have 10's of
thousands of year or even really 10's of years. We have to use intellect
to root out the obviously bad ideas, and even more importantly the
bad-but-not-obviously-bad ideas.
> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.
I'd love to hear your thoughts on why.
-
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!hub1.nntpserver.com!news-out.spamkiller.net!
propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!
news.exit.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Fri, 30 Nov 2001 18:17:43 -0800 (PST)
From: Davide Libenzi <davi...@xmailserver.org>
X-To: Larry McVoy <l...@bitmover.com>
X-cc: Andrew Morton <a...@zip.com.au>, Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>,
lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID:
<linux.kernel.Pine.LNX.4.40.0111301810400.1600-100000@blue1.dev.mcafeelabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 48
On Fri, 30 Nov 2001, Larry McVoy wrote:
> On Fri, Nov 30, 2001 at 05:13:38PM -0800, Davide Libenzi wrote:
> > On Fri, 30 Nov 2001, Larry McVoy wrote:
> > Wait a minute.
> > Wasn't it you that were screaming against Sun, leaving their team because
> > their SMP decisions about scaling sucked, because their OS was bloated
> > like hell with sync spinlocks, saying that they tried to make it scale but
> > they failed miserably ?
>
> Yup, that's me, guilty on all charges.
>
> > What is changed now to make Solaris, a fairly vanishing OS, to be the
> > reference OS/devmodel for every kernel developer ?
>
> It's not. I never said that we should solve the same problems the same
> way that Sun did, go back and read the posting.
This is your quote Larry :
<>
If you want to try and make Linux people work like Sun people, I think
that's going to be tough. First of all, Sun has a pretty small kernel
group, they work closely with each other, and they are full time,
highly paid, professionals working with a culture that is intolerant of
anything but the best. It's a cool place to be, to learn, but I think
it is virtually impossible to replicate in a distributed team, with way
more people, who are not paid the same or working in the same way.
<>
So, if these guys are smart, work hard and are professionals, why did they
take bad design decisions ?
Why didn't they implemented different solutions like, let's say "multiple
independent OSs running on clusters of 4 CPUs" ?
What we really have to like about Sun ?
Me personally, if I've to choose, I'll take the logo.
- Davide
-
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Fri, 30 Nov 2001 18:57:44 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Tim Hockin <thoc...@hockin.org>
cc: Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <200112010202.fB122bE20177@www.hockin.org>
Original-Message-ID: <Pine.LNX.4.33.0111301825150.1296-100000@penguin.transmeta.com>
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: Sat, 1 Dec 2001 03:05:02 GMT
Message-ID: <fa.o9pvfev.h4k7jf@ifi.uio.no>
References: <fa.ffh7gjv.1bn291i@ifi.uio.no>
Lines: 86
On Fri, 30 Nov 2001, Tim Hockin wrote:
>
> > I'm deadly serious: we humans have _never_ been able to replicate
> > something more complicated than what we ourselves are, yet natural
> > selection did it without even thinking.
>
> a very interesting argument, but not very pertinent - we don't have 10's of
> thousands of year or even really 10's of years. We have to use intellect
> to root out the obviously bad ideas, and even more importantly the
> bad-but-not-obviously-bad ideas.
Directed evolution - ie evolution that has more specific goals, and faster
penalties for perceived failure, works on the scale of tens or hundreds of
years, not tens of thousands. Look at dog breeding, but look even more at
livestock breeding, where just a few decades have made a big difference.
The belief that evolution is necessarily slow is totally unfounded.
HOWEVER, the belief that _too_ much direction is bad is certainly not
unfounded: it tends to show up major design problems that do not show up
with less control. Again, see overly aggressive breeding of some dogs
causing bad characteristics, and especially the poultry industry.
And you have to realize that the above is with entities that are much more
complex than your random software project, and where historically you have
not been able to actually influence anything but selection itself.
Being able to influence not just selection, but actually influencing the
_mutations_ that happen directly obviously cuts down the time by another
large piece.
In short, your comment about "not pertinent" only shows that you are
either not very well informed about biological changes, or, more likely,
it's just a gut reaction without actually _thinking_ about it.
Biological evolution is alive and well, and does not take millions of
years to make changes. In fact, most paleolontologists consider some of
the changes due to natural disasters to have happened susprisingly fast,
even in the _absense_ of "intelligent direction".
Of course, at the same time evolution _does_ heavily tend to favour
"stable" life-forms (sharks and many amphibians have been around for
millions of years). That's not because evolution is slow, but simply
because good lifeforms work well in their environments, and if the
environment doesn't change radically they have very few pressures to
change.
There is no inherent "goodness" in change. In fact, there are a lot of
reasons _against_ change, something we often forget in technology. The
fact that evolution is slow when there is no big reason to evolve is a
_goodness_, not a strike against it.
> > Quite frankly, Sun is doomed. And it has nothing to do with their
> > engineering practices or their coding style.
>
> I'd love to hear your thoughts on why.
You heard them above. Sun is basically inbreeding. That tends to be good
to bring out specific characteristics of a breed, and tends to be good for
_specialization_. But it's horrible for actual survival, and generates a
very one-sided system that does not adapt well to change.
Microsoft, for all the arguments against them, is better off simply
because of the size of its population - they have a much wider consumer
base, which in turn has caused them largely to avoid specialization. As a
result, Microsoft has a much wider appeal - and suddenly most of the
niches that Sun used to have are all gone, and its fighting for its life
in many of its remaining ones.
Why do you think Linux ends up being the most widely deployed Unix? It's
avoided niches, it's avoided inbreeding, and not being too directed means
that it doesn't get the problems you see with unbalanced systems.
Face it, being one-sided is a BAD THING. Unix was dying because it was
becoming much too one-sided.
Try to prove me wrong.
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: Fri, 30 Nov 2001 20:02:39 -0700
From: Victor Yodaiken <yodai...@fsmlabs.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Coding style - a non-issue
Original-Message-ID: <20011130200239.A28131@hq2>
Original-References:
<Pine.LNX.4.33L.0111302234420.4079-100...@imladris.surriel.com>
<Pine.LNX.4.33.0111301643170.1224-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0111301643170.1224-100000@penguin.transmeta.com>
User-Agent: Mutt/1.3.23i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: FSM Labs
Date: Sat, 1 Dec 2001 03:10:30 GMT
Message-ID: <fa.b9rni0v.1gje2ph@ifi.uio.no>
References: <fa.o9pve6v.h4c4rb@ifi.uio.no>
Lines: 44
On Fri, Nov 30, 2001 at 04:50:34PM -0800, Linus Torvalds wrote:
>
> You know what the most complex piece of engineering known to man in the
> whole solar system is?
>
> Guess what - it's not Linux, it's not Solaris, and it's not your car.
>
> It's you. And me.
>
> And think about how you and me actually came about - not through any
> complex design.
>
> Right. "sheer luck".
Somehow this does not give me a warm and fuzzy feeling about
the length of the next Linux kernel development cycle.
> And don't EVER make the mistake that you can design something better than
> what you get from ruthless massively parallel trial-and-error with a
> feedback cycle. That's giving your intelligence _much_ too much credit.
Linux is what it is because of design, not accident. And you know
that better than anyone.
If mindless rooting about could make a good OS, then we'd all be using
[ in a rare moment of good sense I don't finish this sentence ]
The question is whether Linux can still be designed at
current scale.
> Quite frankly, Sun is doomed. And it has nothing to do with their
> engineering practices or their coding style.
The San Andreas fault?
-
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Fri, 30 Nov 2001 19:15:55 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Victor Yodaiken <yodai...@fsmlabs.com>
cc: Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <20011130200239.A28131@hq2>
Original-Message-ID: <Pine.LNX.4.33.0111301907010.1296-100000@penguin.transmeta.com>
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: Sat, 1 Dec 2001 03:26:22 GMT
Message-ID: <fa.o99pevv.hku73d@ifi.uio.no>
References: <fa.b9rni0v.1gje2ph@ifi.uio.no>
Lines: 60
On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> > And don't EVER make the mistake that you can design something better than
> > what you get from ruthless massively parallel trial-and-error with a
> > feedback cycle. That's giving your intelligence _much_ too much credit.
>
> Linux is what it is because of design, not accident. And you know
> that better than anyone.
Let's just be honest, and admit that it wasn't designed.
Sure, there's design too - the design of UNIX made a scaffolding for the
system, and more importantly it made it easier for people to communicate
because people had a mental _model_ for what the system was like, which
means that it's much easier to discuss changes.
But that's like saying that you know that you're going to build a car with
four wheels and headlights - it's true, but the real bitch is in the
details.
And I know better than most that what I envisioned 10 years ago has
_nothing_ in common with what Linux is today. There was certainly no
premeditated design there.
And I will claim that nobody else "designed" Linux any more than I did,
and I doubt I'll have many people disagreeing. It grew. It grew with a lot
of mutations - and because the mutations were less than random, they were
faster and more directed than alpha-particles in DNA.
> The question is whether Linux can still be designed at
> current scale.
Trust me, it never was.
And I will go further and claim that _no_ major software project that has
been successful in a general marketplace (as opposed to niches) has ever
gone through those nice lifecycles they tell you about in CompSci classes.
Have you _ever_ heard of a project that actually started off with trying
to figure out what it should do, a rigorous design phase, and a
implementation phase?
Dream on.
Software evolves. It isn't designed. The only question is how strictly you
_control_ the evolution, and how open you are to external sources of
mutations.
And too much control of the evolution will kill you. Inevitably, and
without fail. Always. In biology, and in software.
Amen.
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!
skynet.be!skynet.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: Fri, 30 Nov 2001 19:30:47 -0800
From: Larry McVoy <l...@bitmover.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Victor Yodaiken <yodai...@fsmlabs.com>,
Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Coding style - a non-issue
Original-Message-ID: <20011130193047.H19152@work.bitmover.com>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
Victor Yodaiken <yodai...@fsmlabs.com>,
Rik van Riel <r...@conectiva.com.br>,
Andrew Morton <a...@zip.com.au>, Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>,
linux-ker...@vger.kernel.org
Original-References: <20011130200239.A28131@hq2>
<Pine.LNX.4.33.0111301907010.1296-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.33.0111301907010.1296-100000@penguin.transmeta.com>;
from torvalds@transmeta.com on Fri, Nov 30, 2001 at 07:15:55PM -0800
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 1 Dec 2001 03:32:16 GMT
Message-ID: <fa.h7a0nfv.1264li7@ifi.uio.no>
References: <fa.o99pevv.hku73d@ifi.uio.no>
Lines: 29
On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> > The question is whether Linux can still be designed at
> > current scale.
>
> Trust me, it never was.
Yeah, right, Linus. We should all go home and turn loose the monkeys and
let them pound on the keyboard. They'll just as good a job, in fact, by
your reasoning they'll get there faster, they aren't so likely to waste
time trying to design it.
I can't believe the crap you are spewing on this one and I don't think you
do either. If you do, you need a break. I'm all for letting people explore,
let software evolve, that's all good. But somebody needs to keep an eye on
it.
If that's not true, Linus, then bow out. You aren't needed and *you*
just proved it. You can't have it both ways. Either you are here
for a reason or you aren't. So which is it? You're arguing that you
don't matter. I personally don't agree, I think Linux would be a pile
of dog doo without you. If you don't agree, back off and see what happens.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Fri, 30 Nov 2001 19:34:30 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Larry McVoy <l...@bitmover.com>
cc: Victor Yodaiken <yodai...@fsmlabs.com>,
Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <20011130193047.H19152@work.bitmover.com>
Original-Message-ID: <Pine.LNX.4.33.0111301927510.1296-100000@penguin.transmeta.com>
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: Sat, 1 Dec 2001 03:41:37 GMT
Message-ID: <fa.obppffv.j4u7jd@ifi.uio.no>
References: <fa.h7a0nfv.1264li7@ifi.uio.no>
Lines: 49
On Fri, 30 Nov 2001, Larry McVoy wrote:
>
> I can't believe the crap you are spewing on this one and I don't think you
> do either. If you do, you need a break. I'm all for letting people explore,
> let software evolve, that's all good. But somebody needs to keep an eye on
> it.
Like somebody had to keep an eye on our evolution so that you had a chance
to be around?
Who's naive?
> If that's not true, Linus, then bow out. You aren't needed and *you*
> just proved it.
Oh, absolutely.
I wish more people realized it. Some people realize it only when they get
really pissed off at me and say "Go screw yourself, I can do this on my
own". And you know what? They are right too, even if they come to that
conclusion for what I consider the wrong reasons.
The reason I'm doing Linux is not because I think I'm "needed". It's
because I enjoy it, and because I happen to believe that I'm better than
most at it. Not necessarily better than everybody else around there, but
good enough, and with the social ties to make me unbeatable right now.
But "indispensable"? Grow up, Larry. You give me too much credit.
And why should I bow out just because I'm not indispenable? Are you
indispensable for the continued well-being of humanity? I believe not,
although you are of course free to disagree. Should you thus "bow out" of
your life just because you're strictly speaking not really needed?
Do I direct some stuff? Yes. But, quite frankly, so do many others. Alan
Cox, Al Viro, David Miller, even you. And a lot of companies, which are
part of the evolution whether they realize it or not. And all the users,
who end up being part of the "fitness testing".
And yes, I actually do believe in what I'm saying.
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Fri, 30 Nov 2001 21:15:50 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Victor Yodaiken <yodai...@fsmlabs.com>
cc: Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, <linux-ker...@vger.kernel.org>
Subject: Re: Coding style - a non-issue
In-Reply-To: <20011130214448.A28617@hq2>
Original-Message-ID: <Pine.LNX.4.33.0111302048200.1459-100000@penguin.transmeta.com>
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: Sat, 1 Dec 2001 05:22:53 GMT
Message-ID: <fa.oap9evv.h4253d@ifi.uio.no>
References: <fa.bdbnk8v.1g3e21l@ifi.uio.no>
Lines: 137
On Fri, 30 Nov 2001, Victor Yodaiken wrote:
>
> Ok. There was no design, just "less than random mutations".
> Deep.
I'm not claiming to be deep, I'm claiming to do it for fun.
I _am_ claiming that the people who think you "design" software are
seriously simplifying the issue, and don't actually realize how they
themselves work.
> There was a overall architecture, from Dennis and Ken.
Ask them. I'll bet you five bucks they'll agree with me, not with you.
I've talked to both, but not really about this particular issue, so I
might lose, but I think I've got the much better odds.
If you want to see a system that was more thoroughly _designed_, you
should probably point not to Dennis and Ken, but to systems like L4 and
Plan-9, and people like Jochen Liedtk and Rob Pike.
And notice how they aren't all that popular or well known? "Design" is
like a religion - too much of it makes you inflexibly and unpopular.
The very architecture of UNIX has very much been an evolution. Sure, there
are some basic ideas, but basic ideas do not make a system.
When they say that the devil is in the details, they are trying to tell
you that the details MATTER. In fact, the details matter quite a lot more
than the design ever does.
> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement
Hah.
I don't think I've seen very many examples of that particular design
methodology.
It's impressive that you think this is how stuff gets done, but from
personal experience I would say that it's certainly not true to any
noticeable degree. The impressive part is that Linux development could
_look_ to anybody like it is that organized.
Yes, people read literature too, but that tends to be quite spotty. t's
done mainly for details like TCP congestion control timeouts etc - they
are _important_ details, but at the same time we're talking about a few
hundred lines out of 20 _million_.
And no, I'm no tclaiming that the rest is "random". But I _am_ claiming
that there is no common goal, and that most development ends up being done
for fairly random reasons - one persons particular interest or similar.
It's "directed mutation" on a microscopic level, but there is very little
macroscopic direction. There are lots of individuals with some generic
feeling about where they want to take the system (and I'm obviously one of
them), but in the end we're all a bunch of people with not very good
vision.
And that is GOOD.
A strong vision and a sure hand sound like good things on paper. It's just
that I have never _ever_ met a technical person (including me) whom I
would trust to know what is really the right thing to do in the long run.
Too strong a strong vision can kill you - you'll walk right over the edge,
firm in the knowledge of the path in front of you.
I'd much rather have "brownian motion", where a lot of microscopic
directed improvements end up pushing the system slowly in a direction that
none of the individual developers really had the vision to see on their
own.
And I'm a firm believer that in order for this to work _well_, you have to
have a development group that is fairly strange and random.
To get back to the original claim - where Larry idolizes the Sun
engineering team for their singlemindedness and strict control - and the
claim that Linux seems ot get better "by luck": I really believe this is
important.
The problem with "singlemindedness and strict control" (or "design") is
that it sure gets you from point A to point B in a much straighter line,
and with less expenditure of energy, but how the HELL are you going to
consistently know where you actually want to end up? It's not like we know
that B is our final destination.
In fact, most developers don't know even what the right _intermediate_
destinations are, much less the final one. And having somebody who shows
you the "one true path" may be very nice for getting a project done, but I
have this strong belief that while the "one true path" sometimes ends up
being the right one (and with an intelligent leader it may _mostly_ be the
right one), every once in a while it's definitely the wrong thing to do.
And if you only walk in single file, and in the same direction, you only
need to make one mistake to die.
In contrast, if you walk in all directions at once, and kind of feel your
way around, you may not get to the point you _thought_ you wanted, but you
never make really bad mistakes, because you always ended up having to
satisfy a lot of _different_ opinions. You get a more balanced system.
This is what I meant by inbreeding, and the problem that UNIX
traditionally had with companies going for one niche.
(Linux companies also tend to aim for a niche, but they tend to aim for
_different_ niches, so the end result is the very "many different
directions" that I think is what you _want_ to have to survive).
> > And I will go further and claim that _no_ major software project that has
> > been successful in a general marketplace (as opposed to niches) has ever
> > gone through those nice lifecycles they tell you about in CompSci classes.
>
> That's classic:
> A) "trust me"
> B) now here's a monster bit of misdirection for you to choke on.
>
> Does anyone believe in those stupid software lifcycles?
> No.
> So does it follow that this has anything to do with design?
> No.
Hey, the whole _notion_ of "design" is that you know what you're going to
write, and you design for it.
Or do you have some other meaning of the word "design" that I haven't
heard about.
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: Fri, 30 Nov 2001 21:44:48 -0700
From: Victor Yodaiken <yodai...@fsmlabs.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Victor Yodaiken <yodai...@fsmlabs.com>,
Rik van Riel <r...@conectiva.com.br>, Andrew Morton <a...@zip.com.au>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Coding style - a non-issue
Original-Message-ID: <20011130214448.A28617@hq2>
Original-References: <20011130200239.A28131@hq2>
<Pine.LNX.4.33.0111301907010.1296-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0111301907010.1296-100000@penguin.transmeta.com>
User-Agent: Mutt/1.3.23i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: FSM Labs
Date: Sat, 1 Dec 2001 04:56:56 GMT
Message-ID: <fa.bdbnk8v.1g3e21l@ifi.uio.no>
References: <fa.o99pevv.hku73d@ifi.uio.no>
Lines: 61
On Fri, Nov 30, 2001 at 07:15:55PM -0800, Linus Torvalds wrote:
> And I will claim that nobody else "designed" Linux any more than I did,
> and I doubt I'll have many people disagreeing. It grew. It grew with a lot
> of mutations - and because the mutations were less than random, they were
> faster and more directed than alpha-particles in DNA.
Ok. There was no design, just "less than random mutations".
Deep.
There was a overall architecture, from Dennis and Ken. There
where a couple of good sound design principles, and there were a
couple of people with some sense of how it should work together.
None of that is incompatible with lots of trial and error and learn
by doing.
Here's a characteristic good Linux design method ,( or call it "less than random
mutation method" if that makes you feel happy): read the literature,
think hard, try something, implement
it, find it doesn't do what was hoped and tear the whole thing down.
That's design. Undesigned systems use the method of: implement some crap and then try to
engineer the consequences away.
>
> > The question is whether Linux can still be designed at
> > current scale.
>
> Trust me, it never was.
Trust you? Ha.
> And I will go further and claim that _no_ major software project that has
> been successful in a general marketplace (as opposed to niches) has ever
> gone through those nice lifecycles they tell you about in CompSci classes.
That's classic:
A) "trust me"
B) now here's a monster bit of misdirection for you to choke on.
Does anyone believe in those stupid software lifcycles?
No.
So does it follow that this has anything to do with design?
No.
> Have you _ever_ heard of a project that actually started off with trying
> to figure out what it should do, a rigorous design phase, and a
> implementation phase?
>
> Dream on.
I've seen better arguments in slashdot.
There was no puppet master - ok.
There was no step by step recipe that showed how it should all work - ok
There was no design involved - nope.
-
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>
Subject: Re: Coding style - a non-issue
To: yodai...@fsmlabs.com (Victor Yodaiken)
Original-Date: Sat, 1 Dec 2001 08:57:17 +0000 (GMT)
Cc: torva...@transmeta.com (Linus Torvalds),
yodai...@fsmlabs.com (Victor Yodaiken),
r...@conectiva.com.br (Rik van Riel), a...@zip.com.au (Andrew Morton),
l...@bitmover.com (Larry McVoy),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
In-Reply-To: <20011130214448.A28617@hq2> from "Victor Yodaiken"
at Nov 30, 2001 09:44:48 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: <E16A5xV-0006UL-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: Sat, 1 Dec 2001 08:52:31 GMT
Message-ID: <fa.g13r0nv.k7amp8@ifi.uio.no>
References: <fa.bdbnk8v.1g3e21l@ifi.uio.no>
Lines: 26
> Here's a characteristic good Linux design method ,( or call it "less than random
> mutation method" if that makes you feel happy): read the literature,
> think hard, try something, implement it
That assumes computer science is a functional engineering discipline. Its
not, at best we are at the alchemy stage of progression. You put two things
together it goes bang and you try to work out why.
In many of these fields there is no formal literature. The scientific paper
system in computer science is based on publishing things people already
believe. Much of the rest of the knowledge is unwritten or locked away in
labs as a trade secret, and wil probably never be reused.
Take TCP for example. The TCP protocol is specified in a series of
documents. If you make a formally correct implementation of the base TCP RFC
you won't even make connections. Much of the flow control behaviour, the
queueing and the detail is learned only by being directly part of the
TCP implementing community. You can read all the scientific papers you
like, it will not make you a good TCP implementor.
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!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: a...@zip.com.au (Andrew Morton)
Date: Sat, 1 Dec 2001 10:05:55 +0000 (GMT)
X-Cc: davi...@xmailserver.org (Davide Libenzi), l...@bitmover.com (Larry McVoy),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16A71v-0006h9-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 35
> sufficient for development of a great 1-to-4-way kernel, and
> that the biggest force against that is the introduction of
> fine-grained locking. Are you sure about this? Do you see
> ways in which the uniprocessor team can improve?
ccCluster seems a sane idea to me. I don't by Larry's software engineering
thesis but ccCluster makes sense simply because when you want an efficient
system in computing you get it by not pretending one thing is another.
SMP works best when the processors are not doing anything that interacts
with another CPU.
> key people get atracted into mm/*.c, fs/*.c, net/most_everything
> and kernel/*.c while other great wilderness of the tree (with
> honourable exceptions) get moldier. How to address that?
Actually there are lots of people who work on the driver code nowdays
notably the janitors. The biggest problem there IMHO is that when it comes
to driver code Linus has no taste, so he keeps accepting driver patches
which IMHO are firmly at the hamburger end of "taste"
Another thing for 2.5 is going to be to weed out the unused and unmaintained
drivers, and either someone fixes them or they go down the comsic toilet and
we pull the flush handle before 2.6 comes out.
Thankfully the scsi layer breakage is going to help no end in the area of
clockwork 8 bit scsi controllers, which is major culprit number 1. number 2
is probably the audio which is hopefully going to go away with ALSA based
code.
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!sn-xit-02!sn-xit-01!supernews.com!
newshub2.rdc1.sfba.home.com!news.home.com!newshub1-work.rdc1.sfba.home.com!
gehenna.pell.portland.or.us!nntp-server.caltech.edu!nntp-server.caltech.edu!
mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: l...@bitmover.com (Larry McVoy)
Date: Sat, 1 Dec 2001 10:09:30 +0000 (GMT)
X-Cc: davi...@xmailserver.org (Davide Libenzi), l...@bitmover.com (Larry McVoy),
a...@zip.com.au (Andrew Morton),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16A75O-0006hY-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 15
> > Wasn't it you that were saying that Linux will never scale with more than
> > 2 CPUs ?
>
> No, that wasn't me. I said it shouldn't scale beyond 4 cpus. I'd be pretty
> lame if I said it couldn't scale with more than 2. Should != could.
Question: What happens when people stick 8 threads of execution on a die with
a single L2 cache ?
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
From: Stanislav Meduna <st...@meduna.org>
Message-ID: <linux.kernel.200112012039.fB1KdGq03665@meduna.org>
Subject: Re: Coding style - a non-issue
X-To: linux-ker...@vger.kernel.org
Date: Sat, 1 Dec 2001 21:39:16 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 152
Hello,
wow, what a nice discussion. I am reading the l-k through an
archive, so please forgive me if I am going to say something
that was already said, but I did not yet read it.
Linus wrote:
> Don't underestimate the power of survival of the fittest.
Well, your theory is really an interesting view on the
software development. However, I think that there are
some points that need some more discussion.
First, you are probably right in the long-term. The nature
did have enough time for excursions in one or another
direction - the "project" of life is several orders of magnitude
older than a single generation. You say that it is possible
to help the evolution. But you still need many generations
to be sure that a good result at some stage is not only some
statistical variance.
The technology does not IMHO work that way - Linux (Unix
in all its flavours, Windows, ...) is very young.
We are not in the stage where life exists for millions
of years. We are in the stage where the first cells
have formed and are still quite vulnerable. There is only
a thin line between survival as a kind and extinction (sp?).
I think that in this stage not ignoring the role of
the design is a good thing (and no, I don't believe in God :-)).
Besides that, are you talking about evolution in general,
or about evolution of a particular kind? The competition
is not the same in these cases.
> - massive undirected parallel development ("trial and error")
This is not what is happening here. The parallelism does
exist but is not massive in any way. There are not thousands
of people writing the same stuff. There are not even thousands
of people able to write a good bug report on a particular bug.
There are maybe three (as in the VM recently) authors of some
subsystem and in the end effect there is a God (or two after
a brief disagreement :-)) that decides. No way is this analogous
to the natural selection where the decision happens statistically
on a whole population. This works between Linux and Windows,
but not between implementation ideas.
Al Viro wrote:
> Fact of life: we all suck at reviewing our own code. You, me,
> Ken Thompson, anybody - we tend to overlook bugs in the code
> we'd written. Depending on the skill we can compensate
Absolutely. But what I really miss is an early-warning system.
No matter how good Linus might be in reviewing the submissions,
he cannot catch it all - nobody is _that_ good.
What I feel hurts the Linux is that the testing standards
are very, very low. Heck, Linus does not probably even compile
the code he releases with the widely used configuration options
(otherwise a non-compiling loop.o would not be possible).
Throwing releases onto the public is not testing. Saying
"it works/does not work for me" is not testing. Testing
is _actively_ trying to break things, _very_ preferably
by another person that wrote the code and to do it
in documentable and reproducible way. I don't see many
people doing it.
Linus wrote:
> And I will go further and claim that no major software project
> that has been successful in a general marketplace (as opposed
> to niches) has ever gone through those nice lifecycles they
> tell you about in CompSci classes.
Well, I don't know what they tell in the classes now - I am 33
and in this area the theories change much faster than practice :-)
> Have you ever heard of a project that actually started off
> with trying to figure out what it should do, a rigorous design
> phase, and a implementation phase?
I have heard of projects that did succeeded doing well defined
revision cycles with each cycle figuring out what more or better
it should do, the design of it (more or less rigorous),
implementation, then something what you forgot :-) - testing
and deployment.
The project I am working on now (a process control system)
exists for 15 years and is quite successful. It is vertical
market, not horizontal, but hardly a niche. More control
_did_ help it at one stage, where we had a little quality
crisis.
Maybe it is just because people tend to forget the wrong
things, but I have a strong feeling that Linux starts
to have problems with quality that we did not see before,
at least not in this amount. We are nearly a year in
the stable series and we need to change fundamental things
that broadly affect other parts - VM, devfs, ... This is
not evolution, this is surgery. USB support was one big
argument for 2.4, yet it is far from stable.
My opinion is, that you are _very_ good at maintaining general
overview of a big chunk of code together with being able
to maintain a general direction that makes sense. I don't
think I know someone other that is able to do this. But
I also think that the kernel is in the stage where this
won't be much longer possible even for you. I have seen
software projects going through some kind of crisis
and the symptoms tended be very similar. In the early
stages there are tools (version management, bug reporting
system) and policies (testing standards) that can help.
In the later stages the crisis is in the management.
I cannot say from the outside (I am not doing active kernel
development), in what stage (if in any) the kernel is.
But I have the gut feeling that something should be done.
Evolution does not have the option to vote with its feet.
The people do. While Linux is not much more stable than it
was and goes through a painful stabilization cycle on every
major release, Windows does go up with the general stability with
every release. W2k were better than NT, XP are better than W2k.
Windows (I mean the NT-branch) did never eat my filesystems.
Bad combination of USB and devfs was able to do this in half
an hour, and this was vendor kernel that did hopefully get
more testing than that what is released to the general public.
I surely cannot recommend using 2.4 to our customers.
And frankly, I see the Microsoft borrowing ideas from the open
community. They make things more open - slow, but they are.
They are going to give out compilers for free and charge
for the (quite good and IMHO worth the money) IDE. They are
building communities. Guess why?...
You might of course say that you don't care - the nature
also basically does not care where the evolution is going.
I would like to see more control in the kernel development,
especially regarding quality standards.
Regards
--
Stano
-
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: Coding style - a non-issue
To: st...@meduna.org (Stanislav Meduna)
Original-Date: Sat, 1 Dec 2001 21:18:15 +0000 (GMT)
Cc: linux-ker...@vger.kernel.org
In-Reply-To: <200112012039.fB1KdGq03665@meduna.org>
from "Stanislav Meduna" at Dec 01, 2001 09:39:16 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: <E16AHWZ-0008IS-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: Sat, 1 Dec 2001 21:11:08 GMT
Message-ID: <fa.g4i71nv.14kalp6@ifi.uio.no>
References: <fa.e024ggv.1e1cs3u@ifi.uio.no>
Lines: 20
> "it works/does not work for me" is not testing. Testing
> is _actively_ trying to break things, _very_ preferably
> by another person that wrote the code and to do it
> in documentable and reproducible way. I don't see many
> people doing it.
If you want a high quality, tested supported kernel which has been through
extensive QA then use kernel for a reputable vendor, or do the QA work
yourself or with other people. We have kernel janitors, so why not kernel QA
projects ?
However you'll need a lot of time, a lot of hardware and a lot of attention
to procedure
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>
From: Stanislav Meduna <st...@meduna.org>
Original-Message-Id: <200112020801.fB281Wt07893@meduna.org>
Subject: Re: Coding style - a non-issue
To: linux-ker...@vger.kernel.org
Original-Date: Sun, 2 Dec 2001 09:01:32 +0100 (CET)
In-Reply-To: <E16AHWZ-0008IS-00@the-village.bc.nu>
from "Alan Cox" at dec 01, 2001 09:18:15
X-Mailer: ELM [version 2.5 PL3]
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: Internet mailing list
Date: Sun, 2 Dec 2001 08:04:44 GMT
Message-ID: <fa.dkfmk8v.lkurbs@ifi.uio.no>
References: <fa.g4i71nv.14kalp6@ifi.uio.no>
Lines: 102
> > "it works/does not work for me" is not testing. Testing
> > is _actively_ trying to break things, _very_ preferably
> > by another person that wrote the code and to do it
> > in documentable and reproducible way. I don't see many
> > people doing it.
>
> If you want a high quality, tested supported kernel which has been through
> extensive QA then use kernel for a reputable vendor, or do the QA work
> yourself or with other people.
Correct. But this has one problem - it is splitting resources.
Pushing much of the QA work later in the process means
that the bugs are found later, that there is more people
doing this as absolutely necessary and that much more
communication (and this can be the most important bottleneck)
is needed as necessary.
The need of the VM change is probably a classical example -
why was it not clear at the 2.4.0-pre1, that the current
implementation is broken to the point of no repair? I am
not seeking who is guilty, it is irrelevant, but I think
there is a lesson to be learned and I would like to see
the cause to be identified and steps to be taken that move
such experiments into the development series. The 2.2 also
had issues, but 2.4 has IMHO more issues that are not
localized and fixable without affecting other parts.
Evolution does not need to be efficient. I still think that
software development should be - if we loose half a year,
the more organized competitor will be more than happy.
As a user of the vendor's kernel I have no idea what to do
with a bug. The vendor kernel has hundreds of patches that
are or are not, fully or partially merged into the mainstream
for various reasons - you know this surely much better
than I do :-) Now where do I send a bug report and -
more important - where do I look when I want to have
all available information to an issue, so I can be
more specific (or cancel the report completely because
it is clearly duplicate)? Should I consult my vendor's
bugzilla, systems of all other vendors, l-k and specialized
mailing lists of the given subsystem? I doubt that
many of us will...
There is no single place where the bug reports are sent and -
much more important - where their history can be viewed.
The kernel itself has nothing but linux-kernel (overloaded
with tons of non-relevant stuff such as this thread :-))
and probably various TODO lists of the developers.
I really feel that at least the information should be
centralized so that the info can be hyperlinked. You work
with the kernel so closely that you are probably able
to keep the track of the important issues. 99% of users
wanting to at least report bugs are not. Finding something
in the l-k is hard, but even the managers can normally
operate an issue tracking system - I see them doing it
every day :-)
The classical tools such as version control or issue tracking
system were discussed many times and were rejected - not
by evolution, but by one-man decision. linux-kernel does
not show me when and _why_ something was changed. Changelogs
are big step in the right direction, but I think that more
is needed. Frankly, I think that managing the submissions
in a mail folder of Linus is not the right way of doing this
for a project of this size.
I understand that it is impossible for Linus to write a meaningful
comment and to check in a changeset each time he decides to
accept stuff. I think that at some time he will be forced
to give some write-access to a mainstream branch to a few
other people (btw, this final review is imho in strong conflict
with his evolution theory).
> We have kernel janitors, so why not kernel QA projects ?
Yes, this should be probably discussed. If a development
can be distributed and quite organized at the same time,
so can probably the testing. I have already seen such project
somewhere on the web - no idea where they are now.
But an effective QA project is not possible without support
from the developers themselves. Black-box testing is only
one kind of tests. If a design is not documented, it is
much more harder to try to break it.
> However you'll need a lot of time, a lot of hardware and
> a lot of attention to procedure
I know - our QA department sits next door and this is userspace
application, so hardware does not matter :-)
Regards
--
Stano
-
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>
Subject: Re: Coding style - a non-issue
To: st...@meduna.org (Stanislav Meduna)
Original-Date: Sun, 2 Dec 2001 16:31:27 +0000 (GMT)
Cc: linux-ker...@vger.kernel.org
In-Reply-To: <200112020801.fB281Wt07893@meduna.org>
from "Stanislav Meduna" at Dec 02, 2001 09:01:32 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: <E16AZWZ-0003ml-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: Sun, 2 Dec 2001 16:24:04 GMT
Message-ID: <fa.gvjp1nv.1vnklpd@ifi.uio.no>
References: <fa.dkfmk8v.lkurbs@ifi.uio.no>
Lines: 25
> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair? I am
Because nobody had run good test sets by then - anyway it was repairable.
Linus kept ignoring, refusing and merging conflicting patches. The -ac tree
since 2.4.9-ac or so with Rik's actual fixes he wanted Linus to takes passes
the Red Hat test suite. 2.4.16 kind of passes it now.
It had nothing to do with the VM being broken and everything to do with
what Linus applied. As it happens it looks like the new VM is better
performing for low loads which is good, but the whole VM mess wasn't bad QA
and wasn't bad design.
Linus was even ignoring patches that fixed comments in the VM code that
referenced old behaviour. And due to the complete lack of VM documentation
at the moment I can only assume he's been dropping Andrea's VM comments/docs
too.
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-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.algonet.se!
algonet!newsfeed1.uni2.dk!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>
Subject: Re: Coding style - a non-issue
To: khy...@khyron.com (Khyron)
Original-Date: Sun, 2 Dec 2001 16:33:35 +0000 (GMT)
Cc: linux-ker...@vger.kernel.org (LKML - Linux Kernel Mailing List)
In-Reply-To:
<Pine.BSF.4.33.0112020626460.94365-100000@four.malevolentminds.com>
from "Khyron" at Dec 02, 2001 06:34:17 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: <E16AZYd-0003nZ-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: Sun, 2 Dec 2001 16:26:19 GMT
Message-ID: <fa.h02p47v.1u44q9d@ifi.uio.no>
References: <fa.phashrv.1sm4upo@ifi.uio.no>
Lines: 13
> Bad combination of USB and devfs was able to do this in half
> an hour, and this was *VENDOR KERNEL* that did hopefully get
> more testing than that what is released to the general public.
> I surely cannot recommend using 2.4 to our customers."
So change vendor. There are reasons Red Hat for example does not ship devfs.
It's never been good enough to pass inspection let alone coverage or stress
testing it.
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Message-ID: <linux.kernel.3C0A547B.6BF0B13F@evision-ventures.com>
Date: Sun, 02 Dec 2001 17:19:07 +0100
From: Martin Dalecki <dale...@evision-ventures.com>
Reply-To: dale...@evision.ag
MIME-Version: 1.0
X-To: Alan Cox <a...@lxorguk.ukuu.org.uk>
X-CC: Andrew Morton <a...@zip.com.au>, Davide Libenzi <davi...@xmailserver.org>,
Larry McVoy <l...@bitmover.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Content-Type: text/plain; charset=iso-8859-2
Approved: n...@nntp-server.caltech.edu
Lines: 22
Alan Cox wrote:
> Another thing for 2.5 is going to be to weed out the unused and unmaintained
> drivers, and either someone fixes them or they go down the comsic toilet and
> we pull the flush handle before 2.6 comes out.
>
> Thankfully the scsi layer breakage is going to help no end in the area of
> clockwork 8 bit scsi controllers, which is major culprit number 1. number 2
> is probably the audio which is hopefully going to go away with ALSA based
> code.
Please consider the following wipe out candidates as well:
1. ftape <- it should really really go away
2. proprietary CD-ROM
3. xd.c (ridiculous isn't it?)
4. old ide driver...
5. old directory reading syscalls.
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: dale...@evision.ag
Date: Sun, 2 Dec 2001 16:44:25 +0000 (GMT)
X-Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), a...@zip.com.au (Andrew Morton),
davi...@xmailserver.org (Davide Libenzi),
l...@bitmover.com (Larry McVoy),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16AZj7-0003qD-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 16
> Please consider the following wipe out candidates as well:
>
> 2. proprietary CD-ROM
> 3. xd.c (ridiculous isn't it?)
> 4. old ide driver...
I know people using all 3 of those, while bugs in some of the old scsi 8bit
drivers went unnoticed for a year.
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-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>
From: Stanislav Meduna <st...@meduna.org>
Original-Message-Id: <200112021636.fB2Ga7M01721@meduna.org>
Subject: Re: Coding style - a non-issue
To: linux-ker...@vger.kernel.org
Original-Date: Sun, 2 Dec 2001 17:36:07 +0100 (CET)
In-Reply-To: <E16AZWZ-0003ml-00@the-village.bc.nu> from "Alan Cox"
at dec 02, 2001 04:31:27
X-Mailer: ELM [version 2.5 PL3]
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: Internet mailing list
Date: Sun, 2 Dec 2001 16:43:06 GMT
Message-ID: <fa.dri6cnv.1bhe0a9@ifi.uio.no>
References: <fa.gvjp1nv.1vnklpd@ifi.uio.no>
Lines: 17
> The -ac tree since 2.4.9-ac or so with Rik's actual fixes
> he wanted Linus to takes passes the Red Hat test suite.
> 2.4.16 kind of passes it now.
Is the test suite (or at least part of it) public, or is it
considered to be a trade-secret of Red Hat? I see there
is a "Red Hat Ready Test Suite" - is this a part of it?
Regards
--
Stano
-
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: Coding style - a non-issue
To: st...@meduna.org (Stanislav Meduna)
Original-Date: Sun, 2 Dec 2001 16:57:46 +0000 (GMT)
Cc: linux-ker...@vger.kernel.org
In-Reply-To: <200112021636.fB2Ga7M01721@meduna.org>
from "Stanislav Meduna" at Dec 02, 2001 05:36:07 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: <E16AZw2-0003s4-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: Sun, 2 Dec 2001 16:50:31 GMT
Message-ID: <fa.h2i8nnv.1gg4fpd@ifi.uio.no>
References: <fa.dri6cnv.1bhe0a9@ifi.uio.no>
Lines: 12
> Is the test suite (or at least part of it) public, or is it
> considered to be a trade-secret of Red Hat? I see there
> is a "Red Hat Ready Test Suite" - is this a part of it?
The main Red Hat test suite is a version of Cerberus (originally from VA
and much extended), its all free software and its available somewhere
although I don't have the URL to hand, Arjan ?
-
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/
Date: Tue, 04 Dec 2001 01:00:33 +0100
Message-ID: <20011202.224341.112981324.davem@redhat.com>
Subject: Re: Coding style - a non-issue
From: "David S. Miller" <da...@redhat.com>
In-Reply-To: <E16AZw2-0003s4-00@the-village.bc.nu>
References: <200112021636.fB2Ga7M01721@meduna.org>
<E16AZw2-0003s4-00@the-village.bc.nu>
X-Mailer: Mew version 2.0 on Emacs 21.0 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.954.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.infostrada.it!bofh.it!
robomod
X-Original-Cc: st...@meduna.org, linux-ker...@vger.kernel.org
X-Original-Date: Sun, 02 Dec 2001 22:43:41 -0800 (PST)
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: a...@lxorguk.ukuu.org.uk
Lines: 13
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Date: Sun, 2 Dec 2001 16:57:46 +0000 (GMT)
The main Red Hat test suite is a version of Cerberus (originally from VA
and much extended), its all free software and its available somewhere
although I don't have the URL to hand, Arjan ?
http://people.redhat.com/bmatthews/cerberus/
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Message-ID: <linux.kernel.3C0A54F4.C70C815C@evision-ventures.com>
Date: Sun, 02 Dec 2001 17:21:08 +0100
From: Martin Dalecki <dale...@evision-ventures.com>
Reply-To: dale...@evision.ag
MIME-Version: 1.0
X-To: Alan Cox <a...@lxorguk.ukuu.org.uk>
X-CC: Larry McVoy <l...@bitmover.com>, Davide Libenzi <davi...@xmailserver.org>,
Andrew Morton <a...@zip.com.au>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>, linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Content-Type: text/plain; charset=iso-8859-2
Approved: n...@nntp-server.caltech.edu
Lines: 22
Alan Cox wrote:
>
> > > Wasn't it you that were saying that Linux will never scale with more than
> > > 2 CPUs ?
> >
> > No, that wasn't me. I said it shouldn't scale beyond 4 cpus. I'd be pretty
> > lame if I said it couldn't scale with more than 2. Should != could.
>
> Question: What happens when people stick 8 threads of execution on a die with
> a single L2 cache ?
That had been already researched. Gogin bejoind 2 threads on a single
CPU
engine doesn't give you very much... The first step is giving about 25%
the second only about 5%. There are papers in the IBM research magazine
on
this topic in context of the PowerPC.
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: dale...@evision.ag
Date: Sun, 2 Dec 2001 16:42:59 +0000 (GMT)
X-Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), l...@bitmover.com (Larry McVoy),
davi...@xmailserver.org (Davide Libenzi),
a...@zip.com.au (Andrew Morton),
phill...@bonn-fries.net (Daniel Phillips),
h...@intermeta.de (Henning Schmiedehausen),
jgar...@mandrakesoft.com (Jeff Garzik), linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16AZhj-0003pe-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 19
> > Question: What happens when people stick 8 threads of execution on a die with
> > a single L2 cache ?
>
> That had been already researched. Gogin bejoind 2 threads on a single
> CPU
> engine doesn't give you very much... The first step is giving about 25%
> the second only about 5%. There are papers in the IBM research magazine
> on
The IBM papers make certain architectural assumptions. With some of the
tiny modern CPU cores its going to perfectly viable to put 4 or 8 of them
on one die. At that point cccluster still has to have cluster nodes scaling
to 8 way
-
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!sn-xit-01!
supernews.com!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: l...@bitmover.com (Larry McVoy)
Date: Sun, 2 Dec 2001 21:24:07 +0000 (GMT)
X-Cc: vonbr...@sleipnir.valparaiso.cl (Horst von Brand),
l...@bitmover.com (Larry McVoy), linux-ker...@vger.kernel.org (lkml)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16Ae5n-0004bW-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 29
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines, right?
Linux environment is a single athlon/pii type processor with 128-256Mb of
RAM, because quite simply thats what most developers have.
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then 2->4,
> then 4->8, etc. By your logic, someone should be sitting down and saying
> here is how you get to 128. Other than myself, noone is doing that and
> I'm not really a Linux kernel hack, so I don't count.
The problem being that unless you happen to have a load of people with 128
processor boxes you can't verify your work is even useful or correct.
You can look at Linux development and the areas which have been heavily
funded rather than written for fun/need by people and you'll see a heavy
slant to the enterprise end. J Random Hacker doesn't have an IA64, an 8 way
SMP box or 2Tb of disk so J Random Hacker is much more interested in making
sure his/her webcam works (which is why we pee all over Solaris X86 on device
support).
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/
Message-ID: <200112022252.XAA19497@webserver.ithnet.com>
From: Stephan von Krawczynski <sk...@ithnet.com>
Date: Tue, 04 Dec 2001 01:00:22 +0100
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
User-Agent: IMHO/0.97.1 (Webmail for Roxen)
MIME-Version: 1.0
In-Reply-To: <20011202122940.B2622@work.bitmover.com>
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.382.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!
t-online.de!bofh.it!robomod
References: <20011202122940.B2622@work.bitmover.com>
X-Original-Cc: Horst von Brand <vonbr...@sleipnir.valparaiso.cl>,
Larry McVoy <l...@bitmover.com>, lkml <linux-ker...@vger.kernel.org>
X-Original-Date: Sun, 02 Dec 2001 23:52:32 +0100
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Larry McVoy <l...@bitmover.com>
Lines: 51
> On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> > Just as Linus said, the development is shaped by its environment.
>
> Really? So then people should be designing for 128 CPU machines,
right?
> So why is it that 100% of the SMP patches are incremental? Linux is
> following exactly the same path taken by every other OS, 1->2, then
2->4,
> then 4->8, etc. By your logic, someone should be sitting down and
saying
> here is how you get to 128. Other than myself, noone is doing that
and
> I'm not really a Linux kernel hack, so I don't count.
>
> So why is it that the development is just doing what has been done
before?
Please Larry, have a look at the environment: nobody here owns a box
with 128 CPUs. Most of the people here take care of things they either
- own themselves
- have their hands own at work
- get paid for
You will not find _any_ match with 128 CPUs here.
_Obviously_ you are completely right if this were a company _building_
these boxes. Then your question is the right one, as they would get
paid for the job.
But this is a different environment. As long as you cannot buy these
boxes at some local store for a buck and a bit, you will have no
chance to find willing people for your approach. Therefore it is
absolutely clear, that it will (again) walk the line from 1,2,4,8 ...
CPUs, because the boxes will be available along this line.
I give you this advice: if you _really_ want to move something in this
area, find someone who should care about this specific topic, and has
the money _and_ the will to pay for development of critical GPL code
like this.
Take the _first_ step: create the environment. _Then_ people will come
and follow your direction.
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!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Sun, 2 Dec 2001 15:54:40 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Stephan von Krawczynski <sk...@ithnet.com>
X-Cc: Larry McVoy <l...@bitmover.com>,
Horst von Brand <vonbr...@sleipnir.valparaiso.cl>,
lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011202155440.F2622@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 22
> Please Larry, have a look at the environment: nobody here owns a box
> with 128 CPUs. Most of the people here take care of things they either
> - own themselves
> - have their hands own at work
> - get paid for
>
> You will not find _any_ match with 128 CPUs here.
Nor will you find any match with 4 or 8 CPU systems, except in very rare
cases. Yet changes go into the system for 8 way and 16 way performance.
That's a mistake.
I'd be ecstatic if the hackers limited themselves to what was commonly
available, that is essentially what I'm arguing for.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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!hub1.nntpserver.com!news-out.spamkiller.net!
propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!
news.exit.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Message-ID: <linux.kernel.3C0C9590.6060301@stesmi.com>
Date: Tue, 04 Dec 2001 10:21:20 +0100
From: Stefan Smietanowski <ste...@stesmi.com>
MIME-Version: 1.0
X-To: Larry McVoy <l...@bitmover.com>
X-CC: Stephan von Krawczynski <sk...@ithnet.com>,
Horst von Brand <vonbr...@sleipnir.valparaiso.cl>,
lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Content-Type: text/plain; charset=us-ascii; format=flowed
Approved: n...@nntp-server.caltech.edu
Lines: 36
Larry McVoy wrote:
>>Please Larry, have a look at the environment: nobody here owns a box
>>with 128 CPUs. Most of the people here take care of things they either
>>- own themselves
>>- have their hands own at work
>>- get paid for
>>
>>You will not find _any_ match with 128 CPUs here.
>>
>
> Nor will you find any match with 4 or 8 CPU systems, except in very rare
> cases. Yet changes go into the system for 8 way and 16 way performance.
> That's a mistake.
>
> I'd be ecstatic if the hackers limited themselves to what was commonly
> available, that is essentially what I'm arguing for.
"There are only black cars, we don't make any other color. Noone has
ordered a car with a different color cause we don't accept those orders.
And since noone orders why add colors? Unnecessary cruft."
In essence, People don't run big boxes due to scalability issues, fixing
those might get someone to install a 16-Way.
They sure as hell aren't gonna buy one and then wait around 3 years for
Linux to support it.
// Stefan
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
X-To: ste...@stesmi.com (Stefan Smietanowski)
Date: Tue, 4 Dec 2001 09:40:28 +0000 (GMT)
X-Cc: l...@bitmover.com (Larry McVoy), sk...@ithnet.com (Stephan von Krawczynski),
vonbr...@sleipnir.valparaiso.cl (Horst von Brand),
linux-ker...@vger.kernel.org (lkml)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16BC3w-0001SD-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 11
> In essence, People don't run big boxes due to scalability issues, fixing
> those might get someone to install a 16-Way.
Hackers don't run Linux on 16 way boxes because they cost $100,000 each
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!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Fri, 30 Nov 2001 18:14:15 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Davide Libenzi <davi...@xmailserver.org>
X-Cc: Larry McVoy <l...@bitmover.com>, Andrew Morton <a...@zip.com.au>,
Daniel Phillips <phill...@bonn-fries.net>,
Henning Schmiedehausen <h...@intermeta.de>,
Jeff Garzik <jgar...@mandrakesoft.com>,
lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011130181415.C19152@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 43
On Fri, Nov 30, 2001 at 06:17:43PM -0800, Davide Libenzi wrote:
> > It's not. I never said that we should solve the same problems the same
> > way that Sun did, go back and read the posting.
>
> This is your quote Larry :
>
> <>
> If you want to try and make Linux people work like Sun people, I think
> that's going to be tough. First of all, Sun has a pretty small kernel
> group, they work closely with each other, and they are full time,
> highly paid, professionals working with a culture that is intolerant of
> anything but the best. It's a cool place to be, to learn, but I think
> it is virtually impossible to replicate in a distributed team, with way
> more people, who are not paid the same or working in the same way.
> <>
I'm sorry, I'm lost. You are quoting what I said, that's what I said
said, so what's the point? yes, for the third time, that's what I said
and that's what I meant.
> So, if these guys are smart, work hard and are professionals, why did they
> take bad design decisions ?
> Why didn't they implemented different solutions like, let's say "multiple
> independent OSs running on clusters of 4 CPUs" ?
Because, just like the prevailing wisdom in the Linux hackers, they thought
it would be relatively straightforward to get SMP to work. They started at
2, went to 4, etc., etc. Noone ever asked them to go from 1 to 100 in one
shot. It was always incremental.
I recently talked over the approach I have in mind with the architect of
Sun's multithreaded kernel, the guy who started and guided that effort at
Sun. He agreed that if he had thought of my approach he would have done
it that way. We both agreed it was unlikely that anyone would think of
that approach without first having done it the hard way.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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!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>
Original-Message-Id: <200112012305.fB1N5xf1020409@sleipnir.valparaiso.cl>
To: Larry McVoy <l...@bitmover.com>
cc: lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
In-reply-to: Your message of "Fri, 30 Nov 2001 18:14:15 -0800."
<20011130181415.C19152@work.bitmover.com>
X-Mailer: MH [Version 6.8.4]
X-charset: ISO_8859-1
Original-Date: Sat, 01 Dec 2001 20:05:59 -0300
From: Horst von Brand <vonbr...@sleipnir.valparaiso.cl>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sun, 2 Dec 2001 19:27:25 GMT
Message-ID: <fa.ljpig6v.13kdj5@ifi.uio.no>
References: <fa.h5pqmvv.10m2l28@ifi.uio.no>
Lines: 22
Larry McVoy <l...@bitmover.com> said:
[...]
> Because, just like the prevailing wisdom in the Linux hackers, they thought
> it would be relatively straightforward to get SMP to work. They started at
> 2, went to 4, etc., etc. Noone ever asked them to go from 1 to 100 in one
> shot. It was always incremental.
Maybe that is because 128 CPU machines aren't exactly common... just as
SPARC, m68k, S/390 development lags behind ia32 just because there are
many, many more of the later around.
Just as Linus said, the development is shaped by its environment.
--
Horst von Brand vonbr...@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Sun, 2 Dec 2001 12:29:40 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Horst von Brand <vonbr...@sleipnir.valparaiso.cl>
X-Cc: Larry McVoy <l...@bitmover.com>, lkml <linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011202122940.B2622@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 32
On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote:
> Larry McVoy <l...@bitmover.com> said:
>
> [...]
>
> > Because, just like the prevailing wisdom in the Linux hackers, they thought
> > it would be relatively straightforward to get SMP to work. They started at
> > 2, went to 4, etc., etc. Noone ever asked them to go from 1 to 100 in one
> > shot. It was always incremental.
>
> Maybe that is because 128 CPU machines aren't exactly common... just as
> SPARC, m68k, S/390 development lags behind ia32 just because there are
> many, many more of the later around.
>
> Just as Linus said, the development is shaped by its environment.
Really? So then people should be designing for 128 CPU machines, right?
So why is it that 100% of the SMP patches are incremental? Linux is
following exactly the same path taken by every other OS, 1->2, then 2->4,
then 4->8, etc. By your logic, someone should be sitting down and saying
here is how you get to 128. Other than myself, noone is doing that and
I'm not really a Linux kernel hack, so I don't count.
So why is it that the development is just doing what has been done before?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
X-To: linux-ker...@vger.kernel.org
Orig-Path: forge.intermeta.de!not-for-mail
From: "Henning P. Schmiedehausen" <mailg...@hometree.net>
Orig-Newsgroups: hometree.linux.kernel
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Date: Mon, 3 Dec 2001 23:01:24 +0000 (UTC)
Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
Message-ID: <linux.kernel.9uh084$ome$1@forge.intermeta.de>
Reply-To: h...@intermeta.de
Approved: n...@nntp-server.caltech.edu
Lines: 25
Larry McVoy <l...@bitmover.com> writes:
>then 4->8, etc. By your logic, someone should be sitting down and saying
>here is how you get to 128. Other than myself, noone is doing that and
>I'm not really a Linux kernel hack, so I don't count.
"No one that you know". I'm always surprised that you're able to speak
with such confidence. There may be lots of things going on that don't
daily report to you.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 i...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
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!sn-xit-01!
supernews.com!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Mon, 3 Dec 2001 19:38:15 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: h...@intermeta.de
X-Cc: linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.20011203193815.A7439@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 23
On Mon, Dec 03, 2001 at 11:01:24PM +0000, Henning P. Schmiedehausen wrote:
> Larry McVoy <l...@bitmover.com> writes:
>
> >then 4->8, etc. By your logic, someone should be sitting down and saying
> >here is how you get to 128. Other than myself, noone is doing that and
> >I'm not really a Linux kernel hack, so I don't count.
>
> "No one that you know". I'm always surprised that you're able to speak
> with such confidence. There may be lots of things going on that don't
> daily report to you.
Right you are, but... There is also piles of information that I absorb
on a daily basis, and I'm always willing to be educated. For example,
you could educate me about all those 128 processor Linux boxes in the
world and fill in a hole in my knowledge. I'm listening...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
To: l...@bitmover.com (Larry McVoy)
Original-Date: Tue, 4 Dec 2001 09:07:47 +0000 (GMT)
Cc: h...@intermeta.de, linux-ker...@vger.kernel.org
In-Reply-To: <20011203193815.A7439@work.bitmover.com>
from "Larry McVoy" at Dec 03, 2001 07:38:15 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: <E16BBYJ-0001Jz-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, 4 Dec 2001 09:01:01 GMT
Message-ID: <fa.g24otnv.1064hpc@ifi.uio.no>
References: <fa.i96pn9v.1g46983@ifi.uio.no>
Lines: 12
> you could educate me about all those 128 processor Linux boxes in the
> world and fill in a hole in my knowledge. I'm listening...
There are at least two sets of people working on NUMA machines of that
order, as well as the IBM work on smaller NUMA systems.
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>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: l...@bitmover.com (Larry McVoy), h...@intermeta.de,
linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Original-References: <E16BBYJ-0001Jz...@the-village.bc.nu>
From: Lars Brinkhoff <lars.s...@nocrew.org>
Original-Date: 04 Dec 2001 10:27:10 +0100
In-Reply-To: <E16BBYJ-0001Jz-00@the-village.bc.nu>
Original-Message-ID: <85elmbl4i9.fsf@junk.nocrew.org>
Lines: 11
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
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: nocrew
Date: Tue, 4 Dec 2001 09:31:14 GMT
Message-ID: <fa.jf6hdfv.114m1h8@ifi.uio.no>
References: <fa.g24otnv.1064hpc@ifi.uio.no>
Alan Cox <a...@lxorguk.ukuu.org.uk> writes:
> > you could educate me about all those 128 processor Linux boxes in the
> > world and fill in a hole in my knowledge. I'm listening...
> There are at least two sets of people working on NUMA machines of that
> order, as well as the IBM work on smaller NUMA systems.
Are you NUMA people listening? What do you think of Larry's ideas?
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10
Brinkhoff Consulting http://www.brinkhoff.se/ programming
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Tue, 04 Dec 2001 15:02:54 -0800
From: "Martin J. Bligh" <Martin.Bl...@us.ibm.com>
Reply-To: "Martin J. Bligh" <Martin.Bl...@us.ibm.com>
X-To: Lars Brinkhoff <lars.s...@nocrew.org>, Alan Cox <a...@lxorguk.ukuu.org.uk>
X-cc: Larry McVoy <l...@bitmover.com>, h...@intermeta.de,
linux-ker...@vger.kernel.org
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.2455827301.1007478174@mbligh.des.sequent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 70
>> > you could educate me about all those 128 processor Linux boxes in the
>> > world and fill in a hole in my knowledge. I'm listening...
>> There are at least two sets of people working on NUMA machines of that
>> order, as well as the IBM work on smaller NUMA systems.
>
> Are you NUMA people listening? What do you think of Larry's ideas?
I presume we're talking about what he calls ccClusters or SMP clusters.
I did a little background reading and found a couple of his old posts.
I'm not an expert on this, though I've done some work in the NUMA area.
So I'll stick my neck out for people to chop off - I'm not sure I'd agree with
some of his premises:
> Premise 1: SMP scaling is a bad idea beyond a very small number processors.
> The reasoning for this is that when you start out threading a kernel,
> it's just a few locks. That quickly evolves into more locks, and
> for a short time, there is a 1:1 mapping between each sort of object
> in the system (file, file system, device, process, etc) and a lock.
> So there can be a lot of locks, but there is only one reader/writer
> lock per object instance. This is a pretty nice place to be - it's
> understandable, explainable, and maintainable.
>
> Then people want more performance. So they thread some more and now
> the locks aren't 1:1 to the objects. What a lock covers starts to
> become fuzzy. Thinks break down quickly after this because what
> happens is that it becomes unclear if you are covered or not and
> it's too much work to figure it out, so each time a thing is added
> to the kernel, it comes with a lock. Before long, your 10 or 20
> locks are 3000 or more like what Solaris has. This is really bad,
> it hurts performance in far reaching ways and it is impossible to
> undo.
OK, apart from the fact that there's some leaps of faith here (mostly
due to a lack of detail, I need to go and read some more of his papers),
the obvious objection to this is that just because he's seen it done badly
before, even that it's easy to do badly, it doesn't mean it's impossible to
do it well (it being scalability to many processors).
We will try to make it scale without breaking the low end systems. If we
can, all well and good. If we can't then our patches will get rejected
and we'll all be publicly flogged. Fair enough. And, yes, it's hard. And,
yes, it'll take a while.
But whilst we gradually make scalability better, NUMA boxes will still
work in the meantime - just not quite as fast. I currently have a NUMA
box that thinks it an SMP box ... it still works, just not particularly
efficiently. It will get better.
> Premise 3: it is far easier to take a bunch of operating system images
> and make them share the parts they need to share (i.e., the page
> cache), than to take a single image and pry it apart so that it
> runs well on N processors.
Of course it's easier. But it seems like you're left with much more work to
reiterate in each application you write to run on this thing. Do you want to
do the work once in the kernel, or repeatedly in each application? I'd say
it's a damned sight easier to make an application work well on one big
machine than on a cluster.
I like Linus' opinion on the subject, which I'd boil down to "implement
both, see what works". We must have the most massivly parallel
software engineering team for any OS ever - let's use it ;-)
Martin.
-
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!sfo2-feed1.news.digex.net!intermedia!
news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!
news-in.superfeed.net!news.exit.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Tue, 4 Dec 2001 21:31:40 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-To: "Martin J. Bligh" <Martin.Bl...@us.ibm.com>
X-Cc: Lars Brinkhoff <lars.s...@nocrew.org>, Alan Cox <a...@lxorguk.ukuu.org.uk>,
Larry McVoy <l...@bitmover.com>, <h...@intermeta.de>,
<linux-ker...@vger.kernel.org>
Subject: Re: Linux/Pro [was Re: Coding style - a non-issue]
Message-ID: <linux.kernel.Pine.LNX.4.33L.0112042129160.4079-100000@imladris.surriel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 35
On Tue, 4 Dec 2001, Martin J. Bligh wrote:
> > Premise 3: it is far easier to take a bunch of operating system images
> > and make them share the parts they need to share (i.e., the page
> > cache), than to take a single image and pry it apart so that it
> > runs well on N processors.
>
> Of course it's easier. But it seems like you're left with much more
> work to reiterate in each application you write to run on this thing.
> Do you want to do the work once in the kernel, or repeatedly in each
> application?
There seems to be a little misunderstanding here; from what
I gathered when talking to Larry, the idea behind ccClusters
is that they provide a single system image in a NUMA box, but
with separated operating system kernels.
Of course, this is close to what a "single" NUMA kernel often
ends up doing with much ugliness, so I think Larry's idea to
construct NUMA OSes by putting individual kernels of nodes to
work together makes a lot of sense.
regards,
Rik
--
Shortwave goes a long way: irc.starchat.net #swl
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Tue, 4 Dec 2001 16:36:46 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: "Martin J. Bligh" <Martin.Bl...@us.ibm.com>
X-Cc: Rik van Riel <r...@conectiva.com.br>,
Lars Brinkhoff <lars.s...@nocrew.org>,
Alan Cox <a...@lxorguk.ukuu.org.uk>, Larry McVoy <l...@bitmover.com>,
h...@intermeta.de, linux-ker...@vger.kernel.org
Subject: SMP/cc Cluster description [was Linux/Pro]
Message-ID: <linux.kernel.20011204163646.M7439@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 142
On Tue, Dec 04, 2001 at 03:37:37PM -0800, Martin J. Bligh wrote:
> >> > Premise 3: it is far easier to take a bunch of operating system images
> >> > and make them share the parts they need to share (i.e., the page
> >> > cache), than to take a single image and pry it apart so that it
> >> > runs well on N processors.
> >>
> >> Of course it's easier. But it seems like you're left with much more
> >> work to reiterate in each application you write to run on this thing.
> >> Do you want to do the work once in the kernel, or repeatedly in each
> >> application?
> >
> > There seems to be a little misunderstanding here; from what
> > I gathered when talking to Larry, the idea behind ccClusters
> > is that they provide a single system image in a NUMA box, but
> > with separated operating system kernels.
Right except NUMA is orthogonal, ccClusters work fine on a regular SMP
box.
> OK, then I've partially misunderstood this ... can people provide some
> more reference material? Please email to me, and I'll collate the results
> back to the list (should save some traffic).
I'll try and type in a small explanation, I apologize in advance for the
bervity, I'm under a lot of pressure on the BK front these days...
The most recent set of slides are here:
http://www.bitmover.com/ml/slide01.html
A couple of useful papers are at
http://www.bitmover.com/llnl/smp.pdf
http://www.bitmover.com/llnl/labs.pdf
The first explains why I think fine grained multi threading is a mistake
and the second is a paper I wrote to try and get LLNL to push for what
I called SMP clusters (which are not a cluster of SMPs, they are a
cluster of operating system instances on a single SMP).
The basic idea is this: if you consider the usefulness of an SMP versus a
cluster, the main thing in favor of the SMP is
all processes/processors can share the same memory at memory speeds.
I typically describe this as "all processes can mmap the same data".
A cluster loses here, even if it provides DSM over a high speed
link, it isn't going to have 200 ns caches misses, it's orders of
magnitude slower. For a lot of MPI apps that doesn't matter, but
there are apps for which high performance shared memory is required.
There are other issues like having a big fast bus, load balancing, etc.,
but the main thing is that you can share data quickly and coherently.
If you don't need that performance/coherency and you can afford to
replicate the data, a traditional cluster is a *much* cheaper and
easier answer. Many problems, such as web server farms, are better
done on Beowulf style clusters than an SMP, they will actually scale
better.
OK, so suppose we focus on the SMP problem space. It's a requirement
that all the processes on all the processors need to be able to access
memory coherently. DSM and/or MPI isn't an answer for this problem
space.
The traditional way to use an SMP is to take a single OS image and
"thread" it such that all the CPUs can be in the OS at the same time.
Pretty much all the data structures need to get a lock and each CPU
takes the lock before it uses the data structure. The limit of the
ratio of locks to cache lines is 1:1, i.e., each cache line will need
a lock in order to get 100% of the scaling on the system (yes, I know
this isn't quite true but it is close and you get the idea).
Go read the "smp.pdf" paper for my reasons on why this is a bad approach,
I'll assume for now you are willing to agree that it is for the purposes
of discussion.
If we want to get the most use out of big SMP boxes but we also want to
do the least amount of "damage" in the form of threading complexity in
the source base. This is a "have your cake and eat it too" goal, one
that I think is eminently reachable.
So how I propose we do this is by booting multiple Linux images on
a single box. Each OS image owns part of the machine, 1-4 CPUs, 0 or
more devices such as disk, ethernet, etc., part of memory. In addition,
all OS images share, as a page cache, part of main memory, typically
the bulk of main memory.
The first thing to understand that the *only* way to share data is in
memory, in the globally shared page cache. You do not share devices,
devices are proxied. So if I want data from your disk or file system,
I ask you to put it in memory and then I mmap it. In fact, you really
only share files and you only share them via mmap (yeah, read and write
as well but that's the uninteresting case).
This sharing gets complex because now we have more than one OS image
which is managing the same set of pages. One could argue that the
code complexity is just as bad as a fine grained multi threaded OS
image but that's simply incorrect. I would hide almost 100% of this
code in a file system, with some generic changes (as few as possible)
in the VM system. There are some changes in the process layer as well,
but we'll talk about them later.
If you're sitting here thinking about all the complexity involved in
sharing pages, it is really helpful to think about this in the following
way (note you would not actually implement it like this in the long
run but you could start this way):
Imagine that for any given file system there is one server OS image and N
client os images. Imagine that for each client, there is a proxy process
running on behalf of the client on the server. Sort of like NFS biods.
Each time the client OS wants to do an mmap() it asks the proxy to do
the mmap(). There are some corner cases but if you think about it, by
having the proxies do the mmaps, we *know* that all the server OS data
structures are correct. As far as the server is concerned, the remote
OS clients are no different than the local proxy process. This is from
the correctness point of view, not the performance point of view.
OK, so we've handled setting up the page tables, but we haven't handled
page faults or pageouts. Let's punt on pageouts for the time being,
we can come back to that. Let's figure out a pagefault path that will
give correct, albeit slow, behaviour. Suppose that when the client faults
on a page, the client side file system sends a pagefault message to the
proxy, the proxy faults in the page, calls a new vtop() system call to
get the physical page, and passes that page descriptor back to the client
side. The client side loads up the TLB & page tables and away we go.
Whoops, no we don't, because the remote OS could page out the page and
the client OS will get the wrong data (think about a TLB shootdown that
_didn't_ happen when it should have; bad bad bad). Again, thinking
just from the correctness point of view, suppose the proxy mlock()ed
the page into memory. Now we know it is OK to load it up and use it.
This is why I said skip pageout for now, we're not going to do them
to start with anyway.
OK, so start throwing stones at this. Once we have a memory model that
works, I'll go through the process model.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
X-To: Larry McVoy <l...@bitmover.com>
X-cc: linux-ker...@vger.kernel.org
Subject: Re: SMP/cc Cluster description [was Linux/Pro]
Date: Tue, 04 Dec 2001 18:02:01 -0800
From: er...@uruk.org
Message-ID: <linux.kernel.E16BRNp-0003Ts-00@trillium-hollow.org>
Approved: n...@nntp-server.caltech.edu
Lines: 49
Larry McVoy <l...@bitmover.com> wrote:
> > > There seems to be a little misunderstanding here; from what
> > > I gathered when talking to Larry, the idea behind ccClusters
> > > is that they provide a single system image in a NUMA box, but
> > > with separated operating system kernels.
>
> Right except NUMA is orthogonal, ccClusters work fine on a regular SMP
> box.
...[details omitted for the moment]...
The basic idea seems a sound one, though maybe consider going from
a simple/robust cluster solution back to NUMA boxen. A transparent
virtual computer image is kind of the goal long-term, right?
That is the plan I have for a different OS/kernel I'm working on,
and it seems valid so far.
Uni-proc design plus simple SMP only in the core kernel code fixes
SO many little SMP brain-deadnesses.
For example, there should be no reason that most drivers or any other
random kernel module should know anything about SMP. Under Linux, it
annoys me to no end that I have to ever know (and yes, I count compiling
against "SMP" configuration having to know)... more and more sources of
error.
Then, as long as you make the simple cluster solution handle "hot-swap/
bring-up/tear-down" of nodes from the beginning, you can easily do
things like bring new processor modules, machines, etc. online or out
of your system.
This even argues that you should try working from something like a
Mosix cluster as a starting point, to test it out.
--
Erich Stefan Boleyn <er...@uruk.org> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
-
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!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: SMP/cc Cluster description [was Linux/Pro]
X-To: er...@uruk.org
Date: Wed, 5 Dec 2001 09:09:38 +0000 (GMT)
X-Cc: l...@bitmover.com (Larry McVoy), linux-ker...@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E16BY3e-0005S9-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 18
> For example, there should be no reason that most drivers or any other
> random kernel module should know anything about SMP. Under Linux, it
> annoys me to no end that I have to ever know (and yes, I count compiling
> against "SMP" configuration having to know)... more and more sources of
> error.
Unfortunately the progression with processors seems to be going the
wrong way. Spin locks are getting more not less expensive. That makes
CONFIG_SMP=n a meaningful optimisation for the 99%+ of people not running
SMP
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/