From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41121 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PKtNR-0001cy-8M
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:57:54 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PKtNE-0006t1-Ez
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:57:45 -0500
Received: from mail-gy0-f173.google.com ([209.85.160.173]:39884)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PKtNE-0006st-CX
	for qemu-devel@nongnu.org; Tue, 23 Nov 2010 08:57:32 -0500
Received: by gye5 with SMTP id 5so2855139gye.4
	for <qemu-devel@nongnu.org>; Tue, 23 Nov 2010 05:57:30 -0800 (PST)
Message-ID: <4CEBC83A.2070204@codemonkey.ws>
Date: Tue, 23 Nov 2010 07:57:14 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
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> <4CEB7845.4050104@redhat.com>
In-Reply-To: <4CEB7845.4050104@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: dlaor@redhat.com
Cc: Chris Wright <chrisw@sous-sol.org>, Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org

On 11/23/2010 02:16 AM, Dor Laor wrote:
> On 11/23/2010 08: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.
>
> Why not use cgroup for that?

This is a stop-gap.

The cgroup solution isn't perfect.  It doesn't know anything about guest 
time verses hypervisor time so it can't account just the guest time like 
we do with this implementation.  Also, since it may deschedule the vcpu 
thread while it's holding the qemu_mutex, it may unfairly tax other vcpu 
threads by creating additional lock contention.

This is all solvable but if there's an alternative that just requires a 
small change to qemu, it's worth doing in the short term.

Regards,

Anthony Liguori