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...
