----- Original Message ----- > From: "Anthony Xu" <anthony...@intel.com> > To: "Paolo Bonzini" <pbonz...@redhat.com>, "Yang Zhong" > <yang.zh...@intel.com>, qemu-devel@nongnu.org > Cc: "Chao P Peng" <chao.p.p...@intel.com> > Sent: Friday, March 10, 2017 8:30:06 PM > Subject: RE: [PATCH v1 1/2] reduce qemu's heap Rss size from 12252kB to 2752KB > > > > Ideally, freeing QOM object should not require a global lock. > > > If you see any other QOM requiring a global lock, please let us know, we > > are willing to fix it. > > > > All of them. When unplugging a device, the device object will be freed > > from an RCU callback. > > > > Thanks for your reply, > Some objects may not need lock at all to be freed, > Some objects may just need a small lock to be freed, > > Should we let RCU callbacks to decide which lock they need instead of > enforcing the global lock in RCU thread?
Splitting the global lock and deciding which object requires which lock is very, very hard. The problem is that everything calling object_unref potentially needs the global lock, and that includes the following call chain: object_unref -> memory_region_unref -> flatview_destroy -> flatview_unref -> address_space_update_topology -> memory_region_transaction_commit. Paolo > As for the device object, can we get the global lock inside the object > free/destroy function for now? > > If we can remove the global lock inside RCU thread, we can save 9MB heap > memory, that's a lot! > > Please share with us if you have other idea to do this. > > Thanks > Anthony > > > >
