linux-kernel - Re: x86 status was Re: -mm merge plans for 2.6.23

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.0707111500210.20061@woody.linux-foundation.org>
Date:	Wed, 11 Jul 2007 15:09:28 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrea Arcangeli <andrea@...e.de>
cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: x86 status was Re: -mm merge plans for 2.6.23

On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
>
> I'm going to change topic big time because your sentence above
> perfectly applies to the O(1) scheduler too.

I disagree to a large degree.

We almost never have problems with code you can "think about".

Sure, bugs happen, but code that everybody runs the same generally doesn't 
break. So a CPU scheduler doesn't worry me all that much. CPU schedulers 
are "easy".

What worries me is interfaces to hardware that we know looks different for 
different people. That means that any testing that one person has done 
doesn't necessarily translate to anything at *all* on another persons 
machine.

The timer problems we had when merging the stuff in 2.6.21 just scarred 
me. I'd _really_ hate to have to go through that again. And no, the 
"gradual" thing where the patch that actually *enables* something isn't 
very gradual at all, so that's the absolutely worst kind of thing, because 
then people can "git bisect" to the point where it got enabled and tell us 
that's where things broke, but that doesn't actually say anything at all 
about the patch that actually implements the new behaviour.

So the "enable" kind of patch is actually the worst of the lot, when it 
comes to hardware.

When it comes to pure software algorithms, and things like schedulers, 
you'll still obviously have timing issues and tuning, but generally things 
*work*, which makes it a lot easier to debug and describe.

		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/