qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC PATCH 00/13] PowerPC interrupt rework


From: Matheus K. Ferst
Subject: Re: [RFC PATCH 00/13] PowerPC interrupt rework
Date: Wed, 17 Aug 2022 10:42:06 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 15/08/2022 17:02, Cédric Le Goater wrote:
[ Adding Fabiano who reworked all exception models for 7.0 and Nick
   who rewrote the Linux side sometime ago ]

On 8/15/22 18:20, Matheus Ferst wrote:
Currently, PowerPC interrupts are handled as follows:

1) The CPU_INTERRUPT_HARD bit of cs->interrupt_request gates all
    interrupts;
2) The bits of env->pending_interrupts identify which particular
    interrupt is raised;
3) ppc_set_irq can be used to set/clear env->pending_interrupt bit and
    CPU_INTERRUPT_HARD, but some places access env->pending_interrupt
    directly;
4) ppc_cpu_exec_interrupt is called by cpu_handle_interrupt when
    cs->interrupt_request indicates that there is some interrupt pending.
    This method checks CPU_INTERRUPT_HARD and calls ppc_hw_interrupt. If
    env->pending_interrupt is zero after this call, CPU_INTERRUPT_HARD
    will be cleared.
5) ppc_hw_interrupt checks if there is any unmasked interrupt and calls
    powerpc_excp with the appropriate POWERPC_EXCP_* value. The method
    will also reset the corresponding bit in env->pending_interrupt for
    interrupts that clear on delivery.

If all pending interrupts are masked, CPU_INTERRUPT_HARD will be set,
but ppc_hw_interrupt will not deliver or clear the interrupt, so
CPU_INTERRUPT_HARD will not be reset by ppc_cpu_exec_interrupt. With
that, cs->has_work keeps returning true, creating a loop that acquires
and release qemu_mutex_lock_iothread, causing the poor performance
reported in [1].

This patch series attempts to rework the PowerPC interrupt code to set
CPU_INTERRUPT_HARD only when there are unmasked interrupts. Then
cs->has_work can be simplified to a check of CPU_INTERRUPT_HARD, so it
also only returns true when at least one interrupt can be delivered.

To achieve that, we are basically following Alex Bannée's suggestion[2]
in the original thread: the interrupt masking logic will be factored
out of ppc_hw_interrupt in a new method, ppc_pending_interrupts. This
method is then used to decide if CPU_INTERRUPT_HARD should be set or
cleared after changes to MSR, LPCR, env->pending_interrupts, and
power-management instructions.

We used [3] to check for regressions at each patch in this series. After
patch 12, booting a powernv machine with a newer skiboot with "-smp 4"
goes from 1m09s to 20.79s.

whaou ! PowerNV is really an heavy weight platform, so that's a great
improvement.


Note that this result uses Frederic's test case, where one CPU decompresses the kernel and the others keep spinning to deliver a masked decrement interrupt. The improvement may not be that great with other workloads.

Did you try KVM guests under PowerNV (L1 under an emulated L0) and KVM
under pseries (L2 under an emulated L1) ? Try some intensive I/O on a
SMP machine, like a large scp transfer.


So far, I have mainly tested with buildroot boot+poweroff. I'll try these other tests too.

We should try the MacOS images also.

Thanks,

C.

Unfortunately, I can't test with MacOS :/

Thanks,
Matheus K. Ferst
Instituto de Pesquisas ELDORADO <http://www.eldorado.org.br/>
Analista de Software
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>



reply via email to

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