From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56485)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Z602i-0002g0-T2
	for qemu-devel@nongnu.org; Fri, 19 Jun 2015 13:25:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Z602e-0001D4-TU
	for qemu-devel@nongnu.org; Fri, 19 Jun 2015 13:25:28 -0400
Received: from mail-yk0-f171.google.com ([209.85.160.171]:36304)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Z602e-0001Cw-Q0
	for qemu-devel@nongnu.org; Fri, 19 Jun 2015 13:25:24 -0400
Received: by ykdr198 with SMTP id r198so97536671ykd.3
	for <qemu-devel@nongnu.org>; Fri, 19 Jun 2015 10:25:24 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <55844A0A.2070401@redhat.com>
References: <557B0B21.2030009@hs-rm.de> <55844A0A.2070401@redhat.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Fri, 19 Jun 2015 18:25:03 +0100
Message-ID: <CAFEAcA_zVoBF4pfteyMkS9ObX9uDBbfdK++Ape1_88Ob8zcy1A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QEMU ARM SMP: IPI delivery delayed until next main
 loop event // how to improve IPI latency?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>, =?UTF-8?Q?Alex_Z=C3=BCpke?= <alexander.zuepke@hs-rm.de>

On 19 June 2015 at 17:57, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 12/06/2015 18:38, Alex Z=C3=BCpke wrote:
>>   CPU #0                       CPU #1
>>   =3D=3D=3D=3D=3D=3D                       =3D=3D=3D=3D=3D=3D
>>   ... other stuff ...          WFI (wait for interrupt, like x86 "HLT")
>>   send SGI in MPCore
>>   polls for completeness
>>                  <time passes ...>
>>   polls ...
>>                  <... and passes ...>
>>   still polls ...
>>                  <... and passes ...>
>>   still polls ...
>>                  <... and passes ...>
>
> Shouldn't CPU#0 do a WFE here?  That would work too.

You can do this with SEV/WFE, yes, but you don't have to,
and in fact Linux doesn't currently:
http://lxr.free-electrons.com/source/kernel/smp.c#L108

> Considering that sooner or later we'll have true multithreaded
> emulation, putting a hack doesn't sound like a great prospect.

I'd bet on "later" rather than "sooner", especially if
you want multithreaded on all host architectures.

My not-very-scientific testing of time for a 2xSMP
32-bit Linux guest to boot to userspace shell and
shutdown again suggests it does help: 32.531 secs
vs 34.148 secs. The without-patch version seems more
prone to occasionally stalling so much the boot time
goes up to 45 seconds, too...

-- PMM