From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbEN-0006F2-Ew for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:33:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxbEH-0007HA-Eg for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:32:55 -0500 Received: from [222.73.24.84] (port=63333 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxbEF-0007Gm-Py for qemu-devel@nongnu.org; Wed, 15 Feb 2012 04:32:49 -0500 Message-ID: <4F3B7C4D.3060509@cn.fujitsu.com> Date: Wed, 15 Feb 2012 17:35:09 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F333AAA.1070601@cn.fujitsu.com> <4F333D77.8040104@cn.fujitsu.com> <4F3AA24E.5070201@siemens.com> <4F3AA796.90900@siemens.com> <4F3B2AC8.5030702@cn.fujitsu.com> <4F3B75E3.30005@siemens.com> <4F3B7953.7020006@cn.fujitsu.com> <4F3B7926.7070309@siemens.com> In-Reply-To: <4F3B7926.7070309@siemens.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 10/16 v6] run dump at the background List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Eric Blake , HATAYAMA Daisuke , Dave Anderson , qemu-devel , Luiz Capitulino 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 >