Claudio Fontana <claudio.font...@huawei.com> writes: > On 23.05.2016 14:47, Alex Bennée wrote: >> >> alvise rigo <a.r...@virtualopensystems.com> 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 alex@zen/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 alex@zen/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 <alex.ben...@linaro.org> >>> 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
