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

[Nakajima, Jun]

> 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

> -----Original Message-----
> From: Andi Kleen [mailto:ak@xxxxxxx]
> Sent: Wednesday, September 10, 2003 6:47 PM
> To: Andrew Morton
> Cc: Andi Kleen; richard.brunner@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> torvalds@xxxxxxxx
> Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
> 
> On Wed, Sep 10, 2003 at 06:44:14PM -0700, Andrew Morton wrote:
> > Andi Kleen <ak@xxxxxxx> wrote:
> > >
> > >  +static int is_prefetch(struct pt_regs *regs, unsigned long addr)
> >
> > Can we make this code go away if the configured CPU is, say, Intel?
> > (I couldn't find a sane CONFIG_ setting to use for this).
> 
> It could be done but ... we are moving more and more to generic
kernels
> (e.g. see the alternative patch code which is enabled unconditionally)
> So that when you have a kernel it will boot on near all modern CPUs.
> Currently Athlon and P4 kernels run on each other for example.
> 
> 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.
> 
> >
> > It might be vaguely interesting to add a user-visible counter for
this
> > event? If someone somehow comes up with an application which hits
the
> fault
> > frequently they will take a big performance hit.
> 
> In that case they can just profile the kernel. is_prefetch should
> show it then.
> 
> Of course someone can still add the counter if they want, I'm not
> opposed to it.
> 
> -Andi
> 
> -
> 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/
-
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/