lkml.org 
[lkml]   [2003]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata


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.
>>>>
>>>>
>>>So, basically, if you compile a kernel for a 386, but think that maybe
>>>one day you might need to run it on an Athlon for debugging purposes,
>>>you use 128 byte padding, because it's not too bad on the 386? Seems
>>>pretty wasteful to me when the obvious, simple, elegant solution is to
>>>allow independent selection of workaround inclusion and optimisation.
>>>Especially since half of the work has already been done.
>>>
>>>
>>I missed the "simple, elegant" part. Conceptually elegant maybe.
>>
>>If you mean to use the optimise option only to set cache line size, then
>>that might be a bit saner.
>>
>>As far as the case study goes though: if you were worried about being
>>wasteful, why wouldn't you compile just for the 386 and debug from that?
>>
>
>In the model I'm proposing, the 386 kernel would be missing the Athlon
>workarounds.
>

No, debug the kernel while its running on the 386. And what of my other
concerns?

1. It doesn't appear to be simple and elegant.
2. It would drive developers nuts if it was used for anything other than
a couple of critical functions (cache size would be one).
3. Are there valid situations where you would need it? This isn't a
rhetorical question. Your example would be fine if somebody really
needed to do that.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.072 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site