On Tue, Jul 21, 2009 at 07:39:07PM +0900, Jun Koi wrote: > Hi, > > I play around with MemoryPeek() API on QEMU. While it works well, I > found that it is too slow. Slow in what context ? Are you trying to read large amounts of data out of the guest ? > That is expected because of the way it works: we always need to save > memory to a file, and read it in again, and that is too inefficient. Possibly, but there's quite a few other variables in the stack that could impact performance too. eg you've got at least 3 more data copies in the libvirt RPC layer ontop of that. Also the libvirt RPC layer and API for memory peek has synchronous round-trips which will result in bad throughput if making lot sof peek calls in a row > I am trying to figure out a better way to do this. To do that, clearly > we need to re-architecture QEMU for this: We must have another way to > read memory from outside the QEMU process. > > Anybody could suggest a solution for this problem? I am willing to > spend time on this feature to improve the situation. Could you explain in more detail what you are using the memory peek API for ? That might suggest a completely different libvirt API, or even something outside of libvirft Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list