Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata

[John Bradford]

> > We just got a start on making Linux smaller to encourage embedded use, I
> > don't see adding 300+ bytes of wasted code so people can run
> > misconfigured kernels.
> > 
> > I rather have to patch this in for my Athlon kernels than have people
> > who aren't cutting corners trying to avoid building matching kernels
> > have to live with the overhead.
>
> Overhead? Really you could save more memory by cleaning up a lot of 
> drivers. Andi already said it before, there are better places to be 
> looking at.

That's a non-issue.  300 bytes matters a lot on some systems.  The
fact that there are drivers that are bloated is nothing to do with
it.

> Also 'patching' for Athlon kernels doesn't cut it for people who need to 
> distribute kernels which run on various hardware (such as distros). This 
> alone is benefit enough to justify this supposed 'bloat'.

No it's not.  Most distributions heavily patch the kernel anyway.

It should be possible, and straightforward, to compile a kernel which:

1. Supports, (I.E. has workarounds for), any combination of CPUs.
   E.G. a kernel which supports 386s, and Athlons _only_ would not
   need the F00F bug workaround.  Currently '386' kernels include it,
   because '386' means 'support 386 and above processors'.

2. Has compiler optimisations for one particular CPU.
   E.G. the 386 and Athlon supporting kernel above could have
   alignment optimised for either 386 or Athlon.

This makes it trivial to:

* Make a kernel for a distribution's initial install
  Select all CPUs as supported, and optimise for 686.

* Make an optimised kernel for any system
  Select only the target CPU as supported, and optimise for it

* Make a generic kernel for PIV, and Athlon
  Select PIV and Athlon only as supported.  Optimise for either, or
  optimise for 386, (yes, even though it is not supported), for a
  small kernel, on the basis that it will maximise cache usage, and be
  fairly optimal on both systems.

John.
-
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/