From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH] qemu-kvm: introduce cpu_start/cpu_stop commands Date: Tue, 23 Nov 2010 16:00:53 +0200 Message-ID: <4CEBC915.2010006@redhat.com> References: <1290466818-5230-1-git-send-email-aliguori@us.ibm.com> <4CEB6222.5050203@redhat.com> <4CEBC6E4.1000307@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel@nongnu.org, Chris Wright , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33949 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754323Ab0KWOBE (ORCPT ); Tue, 23 Nov 2010 09:01:04 -0500 In-Reply-To: <4CEBC6E4.1000307@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 11/23/2010 03:51 PM, Anthony Liguori wrote: > On 11/23/2010 12:41 AM, Avi Kivity wrote: >> On 11/23/2010 01:00 AM, Anthony Liguori wrote: >>> qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of >>> teaching >>> them to respond to these signals, introduce monitor commands that >>> stop and start >>> individual vcpus. >>> >>> The purpose of these commands are to implement CPU hard limits using >>> an external >>> tool that watches the CPU consumption and stops the CPU as appropriate. >>> >>> The monitor commands provide a more elegant solution that signals >>> because it >>> ensures that a stopped vcpu isn't holding the qemu_mutex. >>> >> >> From signal(7): >> >> The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored. >> >> Perhaps this is a bug in kvm? > > I need to dig deeper than. Signals are a bottomless pit. > Maybe its something about sending SIGSTOP to a process? AFAIK sending SIGSTOP to a process should stop all of its threads? SIGSTOPping a thread should also work. >> >> If we could catch SIGSTOP, then it would be easy to unblock it only >> while running in guest context. It would then stop on exit to userspace. > > Yeah, that's not a bad idea. Except we can't. > >> Using monitor commands is fairly heavyweight for something as high >> frequency as this. What control period do you see people using? >> Maybe we should define USR1 for vcpu start/stop. >> >> What happens if one vcpu is stopped while another is running? Spin >> loops, synchronous IPIs will take forever. Maybe we need to stop the >> entire process. > > It's the same problem if a VCPU is descheduled while another is running. We can fix that with directed yield or lock holder preemption prevention. But if a vcpu is stopped by qemu, we suddenly can't. > The problem with stopping the entire process is that a big motivation > for this is to ensure that benchmarks have consistent results > regardless of CPU capacity. If you just monitor the full process, > then one VCPU may dominate the entitlement resulting in very erratic > benchmarking. What's the desired behaviour? Give each vcpu 300M cycles per second, or give a 2vcpu guest 600M cycles per second? You could monitor threads separately but stop the entire process. Stopping individual threads will break apart as soon as they start taking locks. -- error compiling committee.c: too many arguments to function