[libvirt] MemoryPeek() is slow

Jun Koi junkoi2004 at gmail.com
Tue Jul 21 15:45:35 UTC 2009


On Tue, Jul 21, 2009 at 7:50 PM, Daniel P. Berrange<berrange at redhat.com> 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




More information about the libvir-list mailing list