Re: [git pull] x86 fixes

From: Ingo Molnar
Date: Tue Sep 09 2008 - 03:28:20 EST



* Valdis.Kletnieks@xxxxxx <Valdis.Kletnieks@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/