Paolo Bonzini <pbonz...@redhat.com> writes: > On 09/05/2016 13:50, Alex Bennée wrote: >> > Which locks? tb_lock during tb_find_fast? The problem with that was >> > that it slowed down everything a lot, wasn't it? >> >> Very much so, in the new tree (coming soon) with QHT I was able to >> remove the locks from the whole hot-path which means they where only >> needed for code generation. > > Okay, I'm curious now. :)
https://github.com/stsquad/qemu/commits/mttcg/base-patches-v3 is the current WIP, with: https://github.com/stsquad/qemu/commit/0823f1c77f12ed5958f77484d6477ea205aee220 being the commit that clears the hot-path to run without locks. The tree is based on tcg-next which has made things a lot cleaner now a bunch of Sergey's stuff has been grabbed by rth. Obviously being WIP subject to change. Once I'm done with my current out-of-tree diversions I'll be back onto cleaning the tree up for the next review round. Review comments on the posted tree's always welcome of course ;-) > >> > To me, the RCU idea is not really about making tb_flush (the rare case) >> > faster; it was more about keeping the rest simple and fast. >> >> I'm not sure it achieved that as there is added complexity from having >> the split buffer and then ensuring you don't double-flush. > > Agreed. > > Paolo -- Alex Bennée
