Re: [libvirt] MemoryPeek() is slow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 23, 2009 at 1:36 PM, Jun Koi<junkoi2004@xxxxxxxxx> wrote:
> On Wed, Jul 22, 2009 at 7:02 PM, Richard W.M. Jones<rjones@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.
>>>
>>> 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.
>>
>> Yes this is correct, and works that way because of how the qemu
>> 'memsave' command works.
>>
>> Also there is a limit on the size of each peek (64K?) which is due to
>> the libvirt remote protocol, specifically the max message size.
>>
>>> 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.
>>
>> A better virDomainMemoryPeek / QEMU memsize would have the following
>> features:
>>
>> (1) Allow large chunks of memory to be snapshotted all in one go.
>> We'd still have to fetch them piece-by-piece because of the max
>> message size in the libvirt remote protocol, but at least the single
>> large snapshot would be more consistent.
>>
>> (2) Don't use the temporary file (?)
>>
>> (3) Be faster, eg. in the non-remote case.
>>
>> (4) Work with Xen and other hypervisors ...
>>
>> (5) Work with physical memory, virtual memory and registers.
>>
>
> On (5): that requires another API, not this virDomainMemoryPeek()

I mean the registers part need a new API.

Thanks,
J

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]