Re: [Xen-devel] [PATCH 2/2] xen: arm: update arm32 assembly primitives to Linux v3.16-rc6

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-07-25 at 17:17 +0100, Julien Grall wrote:
> On 07/25/2014 05:03 PM, Ian Campbell wrote:
> > On Fri, 2014-07-25 at 16:48 +0100, Julien Grall wrote:
> >> On 07/25/2014 04:48 PM, Ian Campbell wrote:
> >>> On Fri, 2014-07-25 at 16:42 +0100, Julien Grall wrote:
> >>>> Hi Ian,
> >>>>
> >>>> On 07/25/2014 04:22 PM, Ian Campbell wrote:
> >>>>> bitops, cmpxchg, atomics: Import:
> >>>>>   c32ffce ARM: 7984/1: prefetch: add prefetchw invocations for 
> >>>>> barriered atomics
> >>>>
> >>>> Compare to Linux we don't have specific prefetch* helpers. We directly
> >>>> use the compiler builtin ones. Shouldn't we import the ARM specific
> >>>> helpers to gain in performance?
> >>>
> >>> My binaries are full of pld instructions where I think I would expect
> >>> them, so it seems like the compiler builtin ones are sufficient.
> >>>
> >>> I suspect the Linux define is there to cope with older compilers or
> >>> something.
> >>
> >> If so:
> > 
> > The compiled output is very different if I use the arch specific
> > explicit variants. The explicit variant generates (lots) more pldw and
> > (somewhat) fewer pld. I've no idea what this means...
> 
> It looks like that pldw has been defined for ARMv7 with MP extensions.
> 
> AFAIU, pldw is used to signal we will likely write on this address.

Oh, I know *that*.

What I couldn't explain is why the builtins should generate 181 pld's
and 6 pldw's (total 187) while the explicit ones generate 127 pld's and
93 pldw's (total 220) for the exact same code base.

Perhaps we simply use prefetchw too often in our code in gcc's opinion
so it elides some of them. Or perhaps the volatile in the explicit
version stops gcc from making other optimisations so there's simply more
occasions where the prefetching is needed.

The difference in the write prefetches is pretty stark though, 6 vs 93.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel