Re: Slowness with multi-thread TCG?

[Frederic Barrat]

On 29/06/2022 00:17, Alex Bennée wrote:
> If you run the sync-profiler (via the HMP "sync-profile on") you can
> then get a breakdown of which mutex's are being held and for how long
> ("info sync-profile").


Alex, a huge thank you!

For the record, the "info sync-profile" showed:
Type               Object  Call site                     Wait Time (s) 
       Count  Average (us)
--------------------------------------------------------------------------------------------------
BQL mutex  0x55eb89425540  accel/tcg/cpu-exec.c:744           96.31578 
    73589937          1.31
BQL mutex  0x55eb89425540  target/ppc/helper_regs.c:207        0.00150 
        1178          1.27


And it points to a lock in the interrupt delivery path, in 
cpu_handle_interrupt().

I now understand the root cause. The interrupt signal for the 
decrementer interrupt remains set because the interrupt is not being 
delivered, per the config. I'm not quite sure what the proper fix is yet 
(there seems to be several implementations of the decrementer on ppc), 
but at least I understand why we are so slow.

With a quick hack, I could verify that by moving that signal out of the 
way, the decompression time of the kernel is now peanuts, no matter the 
number of cpus. Even with one cpu, the 15 seconds measured before was 
already a huge waste, so it was not really a multiple-cpus problem. 
Multiple cpus were just highlighting it.

Thanks again!

  Fred