From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFMCV-0001J8-R2 for qemu-devel@nongnu.org; Wed, 15 Jul 2015 08:54:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFMCS-000458-Jo for qemu-devel@nongnu.org; Wed, 15 Jul 2015 08:54:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFMCS-00044x-FJ for qemu-devel@nongnu.org; Wed, 15 Jul 2015 08:54:12 -0400 References: <1435855010-30882-1-git-send-email-jjherne@linux.vnet.ibm.com> <1435855010-30882-2-git-send-email-jjherne@linux.vnet.ibm.com> <55956A2E.4020806@redhat.com> <55A3CEAF.6030504@linux.vnet.ibm.com> <55A3D5D8.7070902@redhat.com> <55A654D6.5000906@linux.vnet.ibm.com> From: Paolo Bonzini Message-ID: <55A657ED.3070407@redhat.com> Date: Wed, 15 Jul 2015 14:54:05 +0200 MIME-Version: 1.0 In-Reply-To: <55A654D6.5000906@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 1/5] cpu: Provide vcpu throttling interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jjherne@linux.vnet.ibm.com, afaerber@suse.de, amit.shah@redhat.com, dgilbert@redhat.com, borntraeger@de.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org On 15/07/2015 14:40, Jason J. Herne wrote: >>> I'm not sure how callbacks can pile up here. If the vcpus are >>> running then their thread's will execute the callbacks. If they >>> are not running then the use of QEMU_CLOCK_VIRTUAL_RT will >>> prevent the callbacks from stacking because the timer is not >>> running, right? >>=20 >> Couldn't the iothread starve the VCPUs? They need to take the >> iothread lock in order to process the callbacks. >=20 > Yes, I can see the possibility here. I'm not sure what to do about > it though. >=20 > Maybe this is wishful thinking :) But if the iothread lock cannot be=20 > acquired then the cpu cannot run thereby preventing the guest from > changing a ton of pages. This will have the effect of indirectly > throttling the guest which will allow us to advance to the non-live > phase of migration rather quickly. Makes sense. On the other hand this wouldn't prevent callbacks from piling up for a short time because... > And again, if we are starving on > the iothread lock then the guest vcpus are not executing and=20 > QEMU_CLOCK_VIRTUAL_RT is not ticking, right? ... you are talking about stolen time, and QEMU_CLOCK_VIRTUAL_RT does count stolen time (stolen time is different for each VCPU, so you would have a different clock for each VCPU). QEMU_CLOCK_VIRTUAL and QEMU_CLOCK_VIRTUAL_RT(*) only pause across stop/cont. (By the way, the two are the same with KVM). However, something like if (!atomic_xchg(&cpu->throttle_thread_scheduled, 1)) { async_run_on_cpu(cpu, cpu_throttle_thread, NULL); } ... atomic_set(&cpu->throttle_thread_scheduled, 0); g_usleep(...); should be enough. You'd still have many timers that could starve the VCPUs but, as you pointed out, in that case migration would hopefully finish pretty fast. Paolo