Re: Summary of the Arm ports BoF at DC17
- Date: Sun, 17 Sep 2017 23:00:38 +0100
- From: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
- Subject: 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. -- Ben Hutchings friends: People who know you well, but like you anyway.
Description: This is a digitally signed message part