Re: [Qemu-devel] Any topics for today's MTTCG sync-up call?

[Alex Bennée]

Claudio Fontana <address@hidden> writes:

> On 23.05.2016 14:47, Alex Bennée wrote:
>>
>> alvise rigo <address@hidden> writes:
>>
>>> Hi Alex,
>>>
>>> I finally solved the issue I had, the branch is working well as far as I
>>> can say.
>>> The work I will share, in addition to making the LL/SC work mttcg-aware,
>>> extends the various TLB flushes calls with the query-based mechanism: the
>>> requesting CPU queries the flushes to the target CPUs and wait them for
>>> completion.
>>>
>>> Sorry for the delay, I have been quite busy. I just need to polish some
>>> commits, than (this week) I will share the branch.
>>
>> Thanks for the update. It sounds like we don't need to add to that on
>> the call.
>>
>> Anyone else have something they want to discuss?
>
> Hi, at some point in the past there was a set of performance benchmarks which 
> were showing the improvements using mttcg,
> is there some update on that?

I did some basic benchmarks on my last set of enabling patches that
showed a regression in performance for the MTTCG case. This was mostly
due to lock contention in the hot-path (holding lock although not
generating or patching TBs). This had been skipped in Fred's tree
because of the performance impact but wasn't "safe" hence dropped from
the last version.

Since then Emilio's QHT work has made having an un-locked hot-path both
safe and efficient and we are back to having a positive impact from
enabling additional threads. I have been building up a suite of
benchmark tests but I haven't done a full benchmark run on the latest
code. I will do a run when I'm ready to post my next iteration of the
patches.

For a very rough and ready comparison:

14:11 address@hidden/x86_64  [kvm-unit-tests-32bit.git/mttcg/current-tests-v5] 
>time ./arm/run ./arm/locking-test.flat -smp 4 -tcg mttcg=off
/home/alex/lsrc/qemu/qemu.git/arm-softmmu/qemu-system-arm -machine 
virt,accel=tcg -cpu cortex-a15 -device virtio-serial-device -device 
virtconsole,chardev=ctd -chardev testdev,id=ctd -display none -serial stdio 
-kernel ./arm/locking-test.flat -smp 4 -tcg mttcg=off
CPU1: online and ++ing
CPU2: online and ++ing
CPU3: online and ++ing
CPU0: online and ++ing
CPU1: Done, 10000000 incs
CPU2: Done, 10000000 incs
CPU3: Done, 10000000 incs
CPU0: Done, 10000000 incs
XPASS: total incs 40000000

SUMMARY: 1 tests, 1 unexpected failures

real    0m14.399s
user    0m14.368s
sys     0m0.020s
14:14 address@hidden/x86_64  [kvm-unit-tests-32bit.git/mttcg/current-tests-v5] 
>time ./arm/run ./arm/locking-test.flat -smp 4 -tcg mttcg=on
/home/alex/lsrc/qemu/qemu.git/arm-softmmu/qemu-system-arm -machine 
virt,accel=tcg -cpu cortex-a15 -device virtio-serial-device -device 
virtconsole,chardev=ctd -chardev testdev,id=ctd -display none -serial stdio 
-kernel ./arm/locking-test.flat -smp 4 -tcg mttcg=on
CPU1: online and ++ing
CPU2: online and ++ing
CPU3: online and ++ing
CPU0: online and ++ing
CPU2: Done, 10000000 incs
CPU0: Done, 10000000 incs
CPU3: Done, 10000000 incs
CPU1: Done, 10000000 incs
XFAIL: total incs 34052657

SUMMARY: 1 tests, 0 unexpected failures, 1 expected failures

real    0m5.089s
user    0m19.712s
sys     0m0.028s

Note the second test is expected to fail as there is no locking on the
increment. It only flukes it in -tcg mttcg=off mode because of the round
robin scheduling ;-)

>
> Thanks,
>
> Claudio
>
>>
>>>
>>> Best regards,
>>> alvise
>>>
>>> On Mon, May 23, 2016 at 12:57 PM, Alex Bennée <address@hidden>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> It's been a while since the last sync-up call. Have we got any topics to
>>>> discuss today?
>>>>
>>>> Sergey and I (with a little Paolo) have spent some of last week delving
>>>> into the locking hierarchy w.r.t to tb_lock vs mmap_lock to see if there
>>>> is any simplification to be had. I'm not sure if this is a topic
>>>> conducive to a phone call instead of the mailing list but if others want
>>>> to discuss it we can add it as an agenda item.
>>>>
>>>> We also have a new member of the team. Pranith has joined as a GSoC
>>>> student. He'll be looking at memory ordering with his first pass at the
>>>> problem looking to solve the store-after-load issues which do show up on
>>>> ARM-on-x86 (see my testcase).
>>>>
>>>> Alvise, is there any help you need with the LL/SC stuff? The MTTCG aware
>>>> version has been taking some time so would it be worth sharing the
>>>> issues you have hit with the group?
>>>>
>>>> Emilio, is there anything you want to add? I've been following the QHT
>>>> stuff which is a really positive addition which my v3 base patches is
>>>> based upon (making the hot-path non lock contended). Do you have
>>>> anything in the works above that?
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Alex Bennée
>>>>
>>
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée