[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [PATCH 3/4] exec, memory: Call to xen_modified_memory.
On 07/17/2012 09:36 PM, Stefano Stabellini wrote: > On Tue, 17 Jul 2012, Avi Kivity wrote: >> On 07/17/2012 04:59 PM, Anthony PERARD wrote: >> >> >> >> This is pretty ugly. An alternative is to set up a periodic bitmap scan >> >> that looks at the qemu dirty bitmap and calls xen_modified_memory() for >> >> dirty page ranges, and clears the bitmap for the next pass. Is it >> >> workable? >> > >> > I don't think a periodic scan can do anything useful, unfortunately. >> >> Why not? > > I vaguely remember that we used to have a bitmap years ago, but, aside from > making the code much more complicated, it caused blue screens on > intensive disk accesses. Surely it was some bug, not the scan itself. > > >> >> (is xen_modified_memory a hypercall, or does it maintain an in-memory >> >> structure?) >> > >> > It's an hypercall. The function do something (call the hypercall) only >> > during migration, otherwise it return immediately. >> >> I see. I guess it isn't expensive for you because there isn't much dma >> done by qemu usually with xen (unlike kvm where pv block devices are >> implemented in qemu). >> >> How about pushing the call into cpu_physical_memory_set_dirty_flags()? >> Would that reduce the number of call sites? > > Pushing the calls to cpu_physical_memory_set_dirty_flags and > cpu_physical_memory_set_dirty_range would make the code much nicer. > However being these functions in exec-obsolete.h, are they at risk of > removal? exec-obsolete.h just means don't add new call sites. The functions won't be removed, instead they'll be absorbed into the memory code with different names and different implementations. -- error compiling committee.c: too many arguments to function _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |