On Tue, Jul 21, 2009 at 7:50 PM, Daniel P. Berrange<berrange@xxxxxxxxxx> wrote: > 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 ? Yes. > >> 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 That is nothing special. I am working on something like virt-top, which requires to read VM's memory. I am also doing some experiments, which requires to get data out as fast as possible. Really I dont think that current multiple layers are the culprit of the slow problem. It must be the way we are reading memory out, as I wrote above. That is way to inefficient, and nobody can deny that. Thanks, J -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list