Re: [Qemu-devel] [RFC][PATCH 10/16 v6] run dump at the background

[Wen Congyang]

At 02/15/2012 05:21 PM, Jan Kiszka Wrote:
> On 2012-02-15 10:22, Wen Congyang wrote:
>> At 02/15/2012 05:07 PM, Jan Kiszka Wrote:
>>> On 2012-02-15 04:47, Wen Congyang wrote:
>>>> At 02/15/2012 02:27 AM, Jan Kiszka Wrote:
>>>>> On 2012-02-14 19:05, Jan Kiszka wrote:
>>>>>> On 2012-02-09 04:28, Wen Congyang wrote:
>>>>>>> The new monitor command dump may take long time to finish. So we need 
>>>>>>> run it
>>>>>>> at the background.
>>>>>>
>>>>>> How does it work? Like live migration, i.e. you retransmit (overwrite)
>>>>>> already written but then dirtied pages? Hmm... no.
>>>>>>
>>>>>> What does background mean then? What is the use case? What if the user
>>>>>> decides to resume the vm?
>>>>>
>>>>> OK, that is addressed in patch 15! I would suggest merging it into this
>>>>> patch. It makes sense to handle that case gracefully right from the
>>>>> beginning.
>>>>
>>>> OK, I will merge it.
>>>>
>>>>>
>>>>> OK, now I have some other question: What is the point of rate-limiting
>>>>> the dump? The guest is not running, thus not competing for bandwidth.
>>>>
>>>> I use bandwidth to try to control the writing speed. If we write the vmcore
>>>> to disk in a high speed, it may affect some other appilications which use
>>>> the same disk too.
>>>
>>> Just like the guest of that particular VM can do. I don't think we need
>>> this level of control here, it will be provided (if required) at a
>>> different level, affecting the whole QEMU process. Removing the vmcore
>>> bandwidth control will simplify code and user interface.
>>
>> OK. I will implementing it like this:
>> 1. write 100ms
>> 2. sleep 100ms(allow qemu to do the other things)
>> 3. goto 1
> 
> Why? Just write as fast as possible.

If the memory is too big, the command will take too long time. 
Eric said:
  It sounds like it is long-running, which
  means it probably needs to be asynchronous, as well as issue an event
  upon completion, so that other monitor commands can be issued in the
  meantime.

Thanks
Wen Congyang
> 
> Jan
>