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

[Bill Davidsen]

On Sun, 14 Sep 2003, Zwane Mwaikambo wrote:

> On Sun, 14 Sep 2003, bill davidsen wrote:
> 
> > 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.

The best way to remove overhead is not to add it. Putting in 300+ bytes of
code which is pure overhead on anything but an Athlon is silly. And to
justify it because it save effort for people who don't want to bother
building the correct distribution is pure hubris. The Athlon is not so
important that making it run a tiny bit faster justifies taking extra
space on every machine which doesn't benefit.
> 
> 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'.

You clearly think that a kernel will not run on Athlon without this
patch. In real life kernel built for 386, 486, Ppro, etc will run
nicely on every CPU except those less featureful, including the
precious Athlon.

That being the case, there is no justification for forcing the code on
every build rather than putting ifdefs around it. Any vendor who wants
to make Athlon a tiny bit faster at the expense of making every other
system use more memory for code which is never executed can just use the
config option to include the support.

Let's try the facts agin:
1 - the code is not needed for Athlon, prefetch is turned off on broken
    CPUs now. A generic kernel runs fine on Athlon.
2 - the discussion is not on having the code or not, but on putting
    ifdefs around this code so it is only generated if wanted.

Let's not continue to pollute the kernel with architecture dependent
code, we have subtrees for that.

-- 
bill davidsen <davidsen@xxxxxxx>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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