Alexander Spyridakis <a.spyrida...@virtualopensystems.com> writes: > On 24 June 2015 at 17:34, Alex Bennée <alex.ben...@linaro.org> wrote: >> Testing with Alexander's bare metal syncronisation tests fails in MTTCG >> leaving one CPU spinning forever waiting for the second CPU to wake up. >> We simply need to poke the halt_cond once we have processed the PSCI >> power on call. > > Thanks Alex. Works for me, also with qemu_cpu_kick(target_cpu_state) > as Paolo mentioned. > > The test seems to stress the current multi-threaded implementation > quite a lot. With 8 CPUs running, the resulting errors are in the > range of 500 per vCPU (10 million iterations).
We need to get to the bottom of this one first as obviously the implementation needs to bullet proof for all the various synchronisation patterns the CPU can use. > Performance is another issue as mentioned before, but even more > pronounced with 8 cores. Upstream QEMU needs around 10 seconds to > complete, with multi-threading around 100 seconds for the same test. I'm not overly surprised as this is a high-contention test and the additional locking implies a lot of extra overhead. It's certainly a useful test to compare the comparative performance of the various approaches to atomics/exclusives but I hope in real world tasks we gain a bunch of performance for normal unlocked code running across multiple cores. I wonder if the perf tools can give us some insight to where the extra latency is coming from? > > Best regards. -- Alex Bennée
