From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58557 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKtQg-0002jI-6g for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:01:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKtQa-0007Wo-UX for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:01:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKtQa-0007Wd-NA for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:01:00 -0500 Message-ID: <4CEBC915.2010006@redhat.com> Date: Tue, 23 Nov 2010 16:00:53 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu-kvm: introduce cpu_start/cpu_stop commands References: <1290466818-5230-1-git-send-email-aliguori@us.ibm.com> <4CEB6222.5050203@redhat.com> <4CEBC6E4.1000307@codemonkey.ws> In-Reply-To: <4CEBC6E4.1000307@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org 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