[Qemu-devel] MTTCG status updates, benchmark results and KVM forum plans

[Alex Bennée]

Hi,

Numbers!
========

First things first, I ran some more benchmarks on the base patches +
cmpxchg branch over the weekend when I had access to some bigger boxen
which weren't being used. I also added some KVM runs for comparison:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 -smp  on overdrive01 [1]  x -smp 1  on desktop [2]  x -smp 1  on hackbox [3]  
x -smp 1
────────────────────────────────────────────────────────────────────────────────────────
    1              36.995     1.000         243.723     1.000         377.035   
  1.000
    2              21.480     1.722         134.854     1.807         216.337   
  1.743
    3              16.474     2.246         100.090     2.435         163.316   
  2.309
    4              13.671     2.706          83.512     2.918         136.180   
  2.769
    5              12.269     3.015          82.519     2.954         119.261   
  3.161
    6              11.268     3.283          79.589     3.062         110.393   
  3.415
    7                 n/a       n/a          78.338     3.111         105.244   
  3.582
    8                 n/a       n/a          81.091     3.006         103.032   
  3.659
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Footnotes
─────────

[1] pre-production A57, only 6 cores, KVM with -cpu host,aarch64=off

[2] i7-4770 @ 3.4 Ghz, past -smp 5 there is much greater deviation plus
some hangs, best times taken

[3] Xeon X5690 @ 3.47Ghz, 24 cores, -smp 7 number manually calculated

So comparing the numbers on the Xeon monster to my desktop seem to show
we still get a beneficial scaling when the extra cores are real cores
instead of fake hyperthread cores. I only ran up to -smp 8 as that is as
much as the -m virt model will actually accept.

I have noticed some instability in the test though for high -smp values
which caused the test runners timeout protection to kick in. These look
like guest hangs and maybe barrier related (store-after-load re-ordering
can happen). I plan to apply the barrier patches and see if this
improves the stability of the tests.

All in all however the results are pretty promising I'm now running -smp
4 -accel tcg,thread=multi on a fairly regular basis and appreciating the
more snappy response on heavy operations.

MTTCG Call
==========

We've missed a number of the MTTCG calls of late and given the spread of
developers actively working on MTTCG stuff I wonder if we should just
shelve the call and move to regular status updates on the list? I'm
happy to prompt a status thread every couple of weeks if wanted.

As far as I'm aware the following work is still ongoing:

Emilo: cmpxchg atomics
Alvise: LL/SC modelling
Pranith: Memory barrier work (GSoC coming to an end this month)
Nikunj: PPC support for MTTCG

Anyone want to add their status updates? Is anyone else secretly working
on MTTCG related bits who want to make themselves known?

KVM Forum
=========

I'll be at KVM Forum on Toronto next week. Feel free to grab me at
anytime but I'm planning to sign up for a BoF slot on Thursday afternoon
to discuss any outstanding issues for MTTCG and discuss any outstanding
work that needs to be done to be ready for merging when the 2.8
development cycle opens.

From my point of view I think we are looking pretty good for merging but
I would like to get input from the TCG maintainers who are the ones that
will need to accept the work into their tree.

The only current issue I'm aware of is thread safety of the GDB stub.
In theory it is not currently MTTCG safe but it tends to get away with
it because the system is halted when updates are made to the
break/watchpoint lists. I did post a series to RCUify these few months
ago but I dropped it (and the debug asserts) from the base patches
series as it felt a little orthogonal to the main work. My feeling is
this shouldn't be a blocker to MTTCG going in (as it doesn't get any
worse) but we can fix it up in a later series. However I would like to
get the opinions of the maintainers to this approach.

Are there any other issues we should be aware of?

Looking forward to meeting up with other QEMU hackers in the flesh next
week!

Cheers,


--
Alex Bennée