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

[Nick Piggin <piggin@cyberone.com.au>]

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.
>>
>
>My intention is that we won't have done 128 byte alignments just by
>'supporting' Athlons, only if we want to run fast on Athlons.  A
>distribution kernel that is intended to boot on all CPUs needs
>workarounds for Athlon bugs, but it doesn't need 128 byte alignment.
>
>Obviously using such a kernel for anything other than getting a system
>up and running to compile a better kernel is a Bad Thing, but the
>distributions could supply separate Athlon, PIV, and 386 _optimised_
>kernels.
>

Why bother with that complexity? Just use 128 byte lines. This allows
a decent generic kernel. The people who have space requirements would
only compile what they need anyway.

>
>>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
>>
>
>The 'select a single CPU to support and/optimise for' -> 'select a
>bitmap of CPUs to support' work is being done anyway though, so this
>is more or less just one single IFDEF, which is more like a few
>seconds work, rather than a week.
>

While I like Adrian's patch a lot from a functionality and user
simplicity point of view, the key to getting it merged is not to 
increase the complexity of the implementation. The only objections to
the concept came from people who didn't understand it AFAIK.

And too many combinations of ill defined things like this will make 
people (developers) go nuts.