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

richard.brunner
2003-09-11T17:10:58Z

If the program is doing lots of page faults to SEGV signals
intentionally, each of those transitions (exception to-> kernel ->
process -> signal-back to user) is already pretty expensive.
I would think that the slight overhead that is_prefetch()
adds in this case is pretty low in comparision because
the transitions themselves are very expensive in cycles.
Most of the time, is_prefetch should be able to tell if
it is a prefetch from just reading the first byte
(one memory access).

We can measure this for such programs if need be, but, I would bet
we won't see any difference.

Having said that, I'm agnostic to whether is_prefetch()
gets compiled out for non-AMD processors. I defer to
all the kernel experts here if that is feasible or not.

] -Rich ...
] AMD Fellow
] richard.brunner at amd com

> -----Original Message-----
> From: Jamie Lokier [mailto:jamie@shareable.org]
> Sent: Thursday, September 11, 2003 9:55 AM
> To: Brunner, Richard
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
>
>
> richard.brunner@amd.com wrote:
> > Don't worry! I am pretty certain the patch won't impact the
> > performance of the 2.6 kernel on processors from other vendors ;-)
>
> is_prefetch() will slow down programs which depend on lots of SEGV
> signals: those garbage collectors which use mprotect and SIGSEGV to
> track dirty pages.
>
> I wonder how much it will slow them down.
>
> -- Jamie
>