Re: [PATCH] Athlon Prefetch workaround for 2.6.0test6

[Bill Davidsen]

On Tue, 30 Sep 2003, Dave Jones wrote:

> On Mon, Sep 29, 2003 at 09:02:39PM +0000, bill davidsen wrote:
>  > In article <20030929125629.GA1746@averell>, Andi Kleen  <ak@xxxxxx> wrote:

>  > I have to try this on a P4 and K7, but WRT "Only checks on AMD K7+ CPUs"
>  > I hope you meant "only generates code if AMD CPU is target" and not that
>  > the code size penalty is still there for CPUs which don't need it.
> 
> NO NO NO NO NO.
> This *has* to be there on a P4 kernel too, as we can now boot those on a K7 too.
> The 'code size penalty' you talk about is in the region of a few hundred
> bytes. Much less than a page. There are far more obvious bloat candidates.

Clearly you don't do embedded or small applications, and take the attitude
that people should try to find hundreds of bytes elsewhere to compensate
for the bytes you want to force into the kernel to support a bugfix for
one vendor.

You can build a 386 kernel which will run fine on K7 if you are too
limited in resources to build a proper matching kernel for the target
system. The attitude that there is bloat in the kernel already so we can
just add more as long as it doesn't inconvenience you is totally at odds
with the long tradition of Linux being lean and mean.

Linus wouldn't let dump to disk in the kernel because it wasn't generally
useful, I am amazed that he is letting 300 bytes of vendor bugfix which is
totally without value to any other system go in without ifdef's to limit
the memory penalty to the relevant CPUs.

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