[lkml]   [2008]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git pull] x86 fixes

    * <> 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.


     \ /
      Last update: 2008-09-09 09:31    [W:0.021 / U:7.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site