Re: [PATCH] Athlon/Opteron Prefetch Fix for 2.6.0test5 + numbers

[Andi Kleen]

On Tue, 16 Sep 2003 19:44:46 -0700
Andrew Morton <akpm@xxxxxxxx> wrote:

> Andi Kleen <ak@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/