[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CP15 Barrier emulation performance?



On Tue, Jul 11, 2017 at 09:45:49AM +0100, Ian Campbell wrote:
> On Tue, 2017-07-11 at 08:56 +0100, Edmund Grimley Evans wrote:
> > > Does this emulation take a considerable performance hit, as opposed
> > > to
> > > running on armhf hardware/kernel, where the instruction doesn't
> > > appear
> > > to be listed as deprecated?
> > 
> > I'd expect the kernel-emulated instruction to be much slower than any
> > non-emulated instruction, but the overall effect on performance will,
> > of course, depend on how often the instruction is used.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 (where I
> > think I claimed that the instruction is deprecated on armhf hardware
> > but I could easily be wrong)

> Deprecated for both ARMv7 and ARMv8 according to the Kconfig help:
> config CP15_BARRIER_EMULATION
>         bool "Emulate CP15 Barrier instructions"
>         help
>           The CP15 barrier instructions - CP15ISB, CP15DSB, and
>           CP15DMB - are deprecated in ARMv8 (and ARMv7). It is
>           strongly recommended to use the ISB, DSB, and DMB
>           instructions instead.
> 
>           Say Y here to enable software emulation of these
>           instructions for AArch32 userspace code. When this option is
>           enabled, CP15 barrier usage is traced which can help
>           identify software that needs updating.
> 
>           If unsure, say Y
> 
> However I there is a sysctl which allows selecting between "undef",
> "emulated" and "hw" (where the latter is dependent on the hw actually
> supporting the instructions in question). See:
> http://elixir.free-electrons.com/linux/latest/source/Documentation/arm64/legacy_instructions.txt

The ghc sources don't appeart to have direct CP15 instructions, so I suspect
ghc might be calling llvm with options that make it emit CP15 barriers instead
of DMB. Anyways look like a configuration error rather than a coding error.

Riku


Reply to: