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

[Bill Davidsen]

On Mon, 15 Sep 2003, Alan Cox wrote:

> On Llu, 2003-09-15 at 07:32, John Bradford wrote:
> > 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.
> 
> Its kind of irrelevant when by saying "Athlon" you've added 128 byte
> alignment to all the cache friendly structure padding. There are systems
> where memory matters, but spending a week chasing 300 bytes when you can
> knock out 50K is a waste of everyones time. Do the 40K problems first

If we were talking about cleaning the kernel I would agree, and perhaps we
are in the long run. But what is being done here is to add a big chunk of
new code which only benefitts Athlon, and to resist putting ifdefs around
it so the rest of world doesn't have to waste bytes on it.

The config options to reduce kernel size by shedding features for embedded
and similar are new options (relatively). This seems to be the first big
chunk of totally machine dependent code being added after Linux took the
first step back toward being trim again.

No one has come up with any reason why this code can't have an ifdef
around it, other than one claim that distros would not be able to use it
(are there any vendors who can't do a config?) and Andi who would have to
set the config to build one kernel for all his machines.

I have an Athlon, three more on order, and an Athlon laptop in eval. I'm
hardly against them, I just don't want the extra code floating around my
non-Athlon machines. Why is there resistance to making this code
conditional, it's certainly not generally useful, it's a bugfix.

I still like the idea of a single config variable to remove all special
case code for non-configured CPUs, call it NO_BLOAT or MINIMALIST_KERNEL
or EMBEDDED_HELPER as you will. The embedded folks would then have a good
handle to do the work and identify sections to be so identified.

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