[libvirt] MemoryPeek() is slow

Daniel P. Berrange berrange at redhat.com
Tue Jul 21 10:50:21 UTC 2009


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 :|




More information about the libvir-list mailing list