Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 17 Sep 2003 05:25:51 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers |
| |
On Tue, 16 Sep 2003 19:44:46 -0700 Andrew Morton <akpm@osdl.org> wrote:
> Andi Kleen <ak@suse.de> wrote: > > > > > > This is much more efficient than the previous workaround used in the kernel, > > which checked for AMD CPUs in every prefetch(). This can be seen > > in the size of the vmlinux: > > That is hardly a serious comparison: the workaround is just to stop the > oopses while this gets sorted out. It makes no pretense at either > efficiency or permanence.
It was mainly to show that the patch is a better solution than what currently is in the kernel.
> > > Without patch: > > text data bss dec hex filename > > 4020232 665956 169092 4855280 4a15f0 vmlinux > > With patch: > > 4011578 665973 169092 4846643 49f433 > > hrm. Why did data grow?
Probably because of the two __get_user in is_prefetch. I suspect their exception tables get accounted to data.
> > > With prefetch check: 3.7268 microseconds > > Without prefetch check: 3.65945 microseconds > > We don't know how much of this difference is due to removing the branch and > how much is due to reenabling prefetch.
None at all. The test did not measure prefetch performance, but just how much overhead is_prefetch adds to the page fault path. AFAIK there is no prefetch in the do_page_fault -> fail to find vma -> signal delivery path.
As for measuring prefetch I'm not sure it makes sense. It depends a lot on how fast your memory is, how thrashed your caches are, how many CPUs you have (e.g. on Opteron memory latency varies based on the number of CPUs) etc. So even if it isn't a win on some system it can help on others.
> It would be interesting to see comparative benchmarking between prefetch > and no prefetch at all, see whether this feature is worth its icache > footprint.
Maybe. But that would be really a separate thing. even with prefetch completely removed from the kernel we would still need a workaround for user space.
-Andi - 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/
| ![\](/images/icornerr.gif) |