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. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
