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

[richard . brunner]

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@xxxxxxxxxxxxx] 
> Sent: Thursday, September 11, 2003 9:55 AM
> To: Brunner, Richard
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
> 
> 
> richard.brunner@xxxxxxx 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
> 

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