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.
signature.asc
Description: This is a digitally signed message part
