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.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part