From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z86VS-0002KB-3U for qemu-devel@nongnu.org; Thu, 25 Jun 2015 08:43:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z86VN-0007p5-6J for qemu-devel@nongnu.org; Thu, 25 Jun 2015 08:43:50 -0400 Received: from greensocs.com ([193.104.36.180]:40535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z86VM-0007no-Qk for qemu-devel@nongnu.org; Thu, 25 Jun 2015 08:43:45 -0400 Message-ID: <558BF77B.2020803@greensocs.com> Date: Thu, 25 Jun 2015 14:43:39 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <1435160084-938-1-git-send-email-alex.bennee@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] target-arm/psci.c: wake up sleeping CPUs (MTTCG) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Spyridakis , =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: mttcg@listserver.greensocs.com, Peter Maydell , Mark Burton , QEMU Developers On 25/06/2015 01:55, Alexander Spyridakis wrote: > On 24 June 2015 at 17:34, Alex Benn=C3=A9e wro= te: >> Testing with Alexander's bare metal syncronisation tests fails in MTTC= G >> 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). > 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. > > Best regards. Hi, I can reproduce the atomic errors with the test something is definitely=20 wrong. I know about the performance issue I fixed it in the patch-set I'll send. Thanks, Fred