linux-kernel - Re: [git pull] x86 fixes

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]

Date:	Tue, 9 Sep 2008 09:27:51 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Valdis.Kletnieks@...edu
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	x86 maintainers <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] x86 fixes

* Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:

> On Mon, 08 Sep 2008 21:02:49 +0200, Ingo Molnar said:
> 
> > ... and so on it goes with this argument. Everyone has a different 
> > target audience and there's no firm limit. Maybe what makes more sense 
> > is to have some sort of time dependency:
> > 
> >   support all x86 CPUs released in the last year
> >   support all x86 CPUs released in the past 5 years
> >   support all x86 CPUs released in the past 10 years
> >   support all x86 CPUs released ever
> >   [ ... or configure a specific model ]
> > 
> > and people/distributions would use _those_ switches. That means we could 
> > continuously tweak those targets, as systems become obsolete and new 
> > CPUs arrive.
> 
> That's just *asking* for flame mail if somebody builds a kernel for a 
> system that's 4 year 9 months old, and he builds a kernel 6 months 
> later, and it fails to boot because the CPU is now 3 months out and 
> we've deprecated it...

yeah, in terms of precision of the definition it's certainly more 
towards the 'vague' end of the spectrum. OTOH, we do change our defaults 
slowly but surely to match the hardware. So this would give a practical 
definition. If someone _does_ complain legitimately, it doesnt cost us 
much to revert a tweak and delay it some more.

So the idea is to have some sort of independent platform, instead of the 
current practice of distros like Debian chosing pretty much random 
options. No strong opinion though. We can cover 90% of the real 
advantages via dynamic methods, it's quite rare that we have to make 
hard .config choices.

Pretty much the only hardcoded aspect that hurts in practice is the 
cache alignment parameter - all the rest is either dynamic already or 
insignificant. Ever since distros have discovered 
CONFIG_CC_OPTIMIZE_FOR_SIZE=y, even the various compiler optimization 
parameters have less of a role. We just have to wait a year or two for 
P4's to not matter that much anymore, then we can do generic kernels 
with 64 byte alignment and cmov, that will just work almost everywhere 
rather optimally.

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