linux-kernel - Re: [ck] Re: Linus 2.6.23-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0707281445170.3442@woody.linux-foundation.org>
Date:	Sat, 28 Jul 2007 15:18:24 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bill Huey <billh@...ppy.monkey.org>
cc:	Diego Calleja <diegocg@...il.com>,
	jos poortvliet <jos@...nkamer.nl>, ck@....kolivas.org,
	Michael Chang <thenewme91@...il.com>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [ck] Re: Linus 2.6.23-rc1

On Sat, 28 Jul 2007, Bill Huey wrote:
> 
> My argument is that schedule development is open ended. Although having
> a central scheduler to hack is a a good thing, it shouldn't lock out or
> supress development from other groups that might be trying to solve the
> problem in unique ways.

I don't think anything was suppressed here.

You seem to say that more modular code would have helped make for a nicer 
way to do schedulers, but if so, where were those patches to do that? 
Con's patches didn't do that either. They just replaced the code.

In fact, Ingo's patches _do_ add some modularity, and might make it easier 
to replace the scheduler. So it would seem that you would argue for CFS, 
not against it?

> I think that's kind of a bogus assumption from the very get go. Scheduling
> in Linux is one of the most unevolved systems in the kernel that still
> could go through a large transformation and get big gains like what
> we've had over the last few months. This evident with both schedulers,
> both do well and it's a good thing overall the CFS is going in.
> 
> Now, the way it happened is completely screwed up in so many ways that I
> don't see how folks can miss it. This is not just Ingo versus Con, this
> is the current Linux community and how it makes decision from the top down
> and the current cultural attitude towards developers doing things that
> are:

I don't think so.

I think you're barking up the totally wrong tree here.

I think that what happened was very simple: somebody showed that we did 
badly and had benchmarks to show for it, and that in turn resulted in a 
huge spurt of coding from the people involved.

The fact that you think this is "broken" is interesting. I can point to a 
very real example of where this also happened, and where I bet you don't 
think the process was "broken".

Do you remember the mindcraft study?

Exact same thing. Somebody came in, and showed that Linux did really badly 
on some benchmark, and that an alternate approach was much better.

What happened? A huge spurt of development in a pretty short timeframe, 
that totally _obliterated_ the mindcraft results. 

It could have happened independently, but the fact is, it didn't. These 
kinds of events where somebody shows (with real numbers and code) that 
things can be done better really *are* a good way to do development, and 
it's how development generally ends up happening. It's hugely 
motivational, both because competition is motivational in itself, but also 
because somebody shows that things can be done so much better opens 
peoples eyes to it.

And if you think the scheduler situation is different, why? Was it just 
because the mindcraft study compared against Windows NT, not another 
version of Linux patches?

The thing is, development is slow and gradual, but at the same time, it 
happens in spurts (btw, if you have ever studied evolution, you'll find 
the exact same thing: evolution is slow and gradual, but it also happens 
in sudden "spurts" where you have relatively much bigger changes happening 
because you get into a feedback loop).

Another comparison to evolution: most of the competitive pressure actually 
comes from the _same_ species, not from outside. It's not so much rabbits 
competing against foxes (although that happens too), quite a lot of it is 
rabbits competing against other rabbits!

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