qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/arm/virt: Add always-on property to the virt


From: Marc Zyngier
Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: Add always-on property to the virt board timer
Date: Wed, 20 Jan 2016 17:08:36 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 20/01/16 16:47, Andrew Jones wrote:
> On Wed, Jan 20, 2016 at 04:20:03PM +0000, Marc Zyngier wrote:
>> Just tried on Seattle with a 64bit guest, and there is hardly any
>> difference indeed. Both host and guest are "mostly" defconfig as well.
>> So there is a kernel configuration difference.
>>
>> Running my 32bit guest on a 64bit host definitely shows a massive
>> difference (with 8 vcpus):
>>
>> Without "always-on": ~1200 interrupts per second
>> With "always-on": ~50 interrupts per second
>>
>> [Head scratching, poking Mark]
>>
>> Right, I now know what is going on: The arm64 kernel uses
>> tick_setup_hrtimer_broadcast() so that it can still use the arch timer
>> as a broadcast timer (forcing one CPU to remain on), while the 32bit
>> kernel relies on the presence of a backup timer (sp804 anyone?) or the
>> guarantee that the timer cannot go away (always-on).
>>
>> This is probably why I'm seeing such a gain with a 32bit guest, and none
>> with a 64bit guest (the kernel already does the right thing). As to why
>> there is such a difference between the two architectures, this is a
>> story for another day...
>>
> 
> Thanks Marc! I just confirmed with an AArch32 guest using QEMU, and the
> patch we've hijacked for this thread. Without the patch I get a megaton
> of interrupts (~14000/s). With the patch, after letting the guest chill
> for a while, I'm getting ~150/s (8 vcpus).
> 
> I guess I don't have a test case for the ACPI code though. afaik we only
> have UEFI for AArch64 guests, and we don't have ACPI boot without UEFI.
> Or maybe I can hack time_init to remove the tick_setup_hrtimer_broadcast
> call?

Yeah, that should work.

Thanks,

        M.
-- 
Jazz is not dead. It just smells funny...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]