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

I have to agree with what Andi says. It is in a slow path,
and we want to guard against user programs that could hit it.
Making it conditional doesn't buy a lot and would cause lots of
re-validation of the patch that we would like
to avoid so we can get this in to the 2.6 kernel ASAP.
Don't worry! I am pretty certain the patch won't impact the
performance of the 2.6 kernel on processors from other vendors ;-)

Thanks!
]-Rich ...
]AMD Fellow
> From: Nakajima, Jun [mailto:jun.nakajima@intel.com]
>
> > I would hate to break this again just to save a few hundred bytes in
> > this function. Also the overhead is very low so it is also not
> > interesting to make it conditional for speed reasons.
>
> For maintenance and testing purposes, I think it's still
> better to make it conditional. If the errata are fixed, you
> might want to kill the condition depending on the stepping,
> for example. During the transition time, you need to support
> both the steppings until old ones go away (then remove the
> workaround).
>
> Thanks,
> Jun

-
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.134 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site