Avi Kivity wrote:
On 04/23/2010 12:59 PM, Yoshiaki Tamura wrote:
Avi Kivity wrote:
On 04/21/2010 08:57 AM, Yoshiaki Tamura wrote:
Currently buf size is fixed at 32KB. It would be useful if it could
be flexible.
Why is this needed? The real buffering is in the kernel anyways; this is
only used to reduce the number of write() syscalls.
This was introduced to buffer the transfered guests image transaction
ally on the receiver side. The sender doesn't use it.
In case of intermediate state, we just discard this buffer.
How large can it grow?
It really depends on what workload is running on the guest, but it should be as
large as the guest ram size in the worst case.
What's wrong with applying it (perhaps partially) to the guest state?
The next state transfer will overwrite it completely, no?
AFAIK, the answer is no.
qemu_loadvm_state() calls load handlers of each device emulator, and they will
update its state directly, which means even if the transaction was not complete,
it's impossible to recover the previous state if we don't make a buffer.
I guess your concern is about consuming large size of ram, and I think having an
option for writing the transaction to a temporal disk image should be effective.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
