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

[bill davidsen]

In article <20030912195606.24e73086.ak@xxxxxxx>,
Andi Kleen  <ak@xxxxxxx> wrote:
| On 12 Sep 2003 11:32:42 -0600
| ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
| 
| 
| > There may be better places to attack.  But new code is what is up for
| > examination and is easiest to fix.
| 
| With is_prefetch:
| 
|    text    data     bss     dec     hex filename
|    2782       4       0    2786     ae2 arch/i386/mm/fault.o
| 
| Without is_prefetch:
| 
|  text    data     bss     dec     hex filename
|    2446       4       0    2450     992 arch/i386/mm/fault.o
| 
| Difference 332 bytes
| 
| If you start your attack on 332 bytes then IMHO you have your priorities wrong ;-)
| 
| The main reason I'm really against this is that currently the P4 kernels work
| fine on Athlon. Just when is_prefetch is not integrated in them there will 
| be an mysterious oops once every three months in the kernel in prefetch
| on Athlon.
|  
| That would be bad. The alternative would be to prevent the P4 kernel
| from booting on the Athlon at all, but doing that for 332 bytes
| would seem a bit silly.

I am really missing something here, why is it you want to run a P4
kernel on Athlon? And why is it good to push bloat into the kernel and
then tell people who really care about size to go peddle their papers
elsewhere? There is perfectly good code in the kernel now to disable
prefetch on Athlon, leave it in unless the kernel is built for Athlon
support. A P4 kernel should run fine on an Athlon already.

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