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

John Bradford
2003-09-15T10:41:07Z

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

John.