Messages in this thread | | | From | richard.brunner@amd ... | Subject | RE: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata | Date | Thu, 11 Sep 2003 12:09:58 -0500 |
| |
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 >
- 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/
| |