Web lists-archives.com

Re: Summary of the Arm ports BoF at DC17

On Sun, 2017-09-17 at 21:30 +0100, Colin Watson wrote:
> On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote:
> > On 2017-09-15, Ben Hutchings wrote:
> > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > > [...]
> > > > There is optional kernel support to trap the exceptions here
> > > > and emulate the instructions, but it's really not recommended for
> > > > serious use (e.g. on a build machine!).
> > > 
> > > [...]
> > > 
> > > Why is it not recommended?  Terrible performance, or known bugs?
> > 
> > On arm64 kernels building armhf packages for the reproducible builds
> > builders,
> Steve was mostly talking about armel, I thought?
> I can't really speak for how it would be on armel, but I rather suspect
> that decent ARMv8 hardware would be sufficiently much faster than
> ARMv7-or-earlier kit to more than cancel out performance losses from
> instruction emulation.

For armel, we can't assume there *are* any memory barrier instructions.
 Instead, atomic operations libraries or code generators should use the
kuser helper memory_barrier(), which will do the right thing on an SMP
system and nothing on a UP system.  (kuser helpers are user-mode
functions exposed by the kernel.)

So far as I can see, there are three sets of deprecated and emulated
instructions and I think they should be replaced as follows:

                     min. arch   armel            armhf
                     ---------   -----            -----
swp/swpb             ARMv4?      kuser cmpxchg()  ldrex+strex
cp15 memory barrier  ARMv6       N/A              dmb/dsb/isb
setend               ARMv6       N/A              rev/rev16

(I think swp/swpb were originally specified to bypass the data cache,
which meant they was never useful in user mode armel code.)


Ben Hutchings
friends: People who know you well, but like you anyway.

Attachment: signature.asc
Description: This is a digitally signed message part