On Thu, Aug 9, 2012 at 4:18 PM, Avi Kivity <a...@redhat.com> wrote: > On 08/09/2012 10:49 AM, Paolo Bonzini wrote: >> Il 09/08/2012 09:33, liu ping fan ha scritto: >>> Yes, it is to defer destructors. >>> See 0009-memory-prepare-flatview-and-radix-tree-for-rcu-style.patch >>> When MemoryRegion is _del_subregion from mem in updater, it may be >>> still in use by reader -- radix or flatview, so defer its destructors >>> to the reclaimer --phys_map_release(PhysMap *map) >> >> How are you sure that the reader is already out of its critical section >> by the time the reclaimer runs? >> >>> If we have rcu, it could be elegant to do this. >> >> Yeah, I think inventing primitives is dangerous and difficult to review; >> and it may be difficult to replace it with proper call_rcu. >> >> You should probably make a proof-of-concept using liburcu. Then we can >> decide how to implement RCU in a way that is portable enough for QEMU's >> needs. > > IMO we should start with a simple mutex (which will cover only the > lookup and map rebuild). This should reduce the contention to basically > nothing (still leaving a cache line bounce). If a profile shows the > cache line bounce hurting us, or perhaps contention in ultralarge > guests, then we should switch to rcu. > Agree, I think this will pin us on the major issue -- mmio perfermance
Regards, pingfan > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
