From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56129 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9HTM-0007Mt-EC for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:48:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9HT2-0005uD-R2 for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:47:50 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:48095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9HT2-0005u1-Ka for qemu-devel@nongnu.org; Mon, 11 Apr 2011 09:47:48 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3BDVmiu029290 for ; Mon, 11 Apr 2011 07:31:48 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3BDlg6Z110816 for ; Mon, 11 Apr 2011 07:47:42 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3BDlfi3000455 for ; Mon, 11 Apr 2011 07:47:41 -0600 Message-ID: <4DA30679.7060205@us.ibm.com> Date: Mon, 11 Apr 2011 08:47:37 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 3/5] hpet 'driftfix': add fields to HPETTimer and VMStateDescription References: <148574451.12234.1302512788577.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4DA2C4F2.1000002@redhat.com> <4DA2FDA8.9070109@us.ibm.com> <1302529181.3021.13.camel@mothafucka.localdomain> In-Reply-To: <1302529181.3021.13.camel@mothafucka.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: kvm@vger.kernel.org, jan kiszka , qemu-devel@nongnu.org, gcosta@redhat.com, Ulrich Obergfell , Avi Kivity On 04/11/2011 08:39 AM, Glauber Costa wrote: > On Mon, 2011-04-11 at 08:10 -0500, Anthony Liguori wrote: >> On 04/11/2011 04:08 AM, Avi Kivity wrote: >>> On 04/11/2011 12:06 PM, Ulrich Obergfell wrote: >>>>>> vmstate_hpet_timer = { >>>>>> VMSTATE_UINT64(fsb, HPETTimer), >>>>>> VMSTATE_UINT64(period, HPETTimer), >>>>>> VMSTATE_UINT8(wrap_flag, HPETTimer), >>>>>> + VMSTATE_UINT64_V(saved_period, HPETTimer, 3), >>>>>> + VMSTATE_UINT64_V(ticks_not_accounted, HPETTimer, 3), >>>>>> + VMSTATE_UINT32_V(irqs_to_inject, HPETTimer, 3), >>>>>> + VMSTATE_UINT32_V(irq_rate, HPETTimer, 3), >>>>>> + VMSTATE_UINT32_V(divisor, HPETTimer, 3), >>>>> We ought to be able to use a subsection keyed off of whether any >>>> ticks >>>>> are currently accumulated, no? >>>> >>>> Anthony, >>>> >>>> I'm not sure if I understand your question correctly. Are you suggesting >>>> to migrate the driftfix-related state conditionally / only if there are >>>> any ticks accumulated in 'ticks_not_accounted' and 'irqs_to_inject' ? >>>> >>>> The size of the driftfix-related state is 28 bytes per timer and we have >>>> 32 timers per HPETState, i.e. 896 additional bytes per HPETState. With a >>>> maximum number of 8 HPET blocks (HPETState), this amounts to 7168 bytes. >>>> Hence, unconditional migration of the driftfix-related state should not >>>> cause significant additional overhead. >>>> >>> It's not about overhead. >>> >>>> Maybe I missed something. Could you please explain which benefit you see >>>> in using a subsection ? >>> In the common case of there being no drift, you can migrate from a >>> qemu that supports driftfix to a qemu that doesn't. >>> >> Right, subsections are a trick. The idea is that when you introduce new >> state for a device model that is not always going to be set, when you do >> the migration, you detect whether the state is set or not and if it's >> not set, instead of sending empty versions of that state (i.e. >> missed_ticks=0) you just don't send the new state at all. >> >> This means that you can migrate to an older version of QEMU provided the >> migration would work correctly. > Using subsections and testing for hpet option being disabled vs enabled, > is fine. But checking for the existence of drift, like you suggested (or > at least how I understood you), is very tricky. It is expected to change > many times during guest lifetime, and would make our migration > predictability something Heisenberg would be proud of. Is this true? I would expect it to be very tied to workloads. For idle workloads, you should never have accumulated missed ticks whereas with heavy workloads, you always will have accumulated ticks. Is that not correct? Regards, Anthony Liguori