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
