From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35240 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pfy3v-0005pT-4x
	for qemu-devel@nongnu.org; Thu, 20 Jan 2011 12:12:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1Pfy3g-0003jm-U9
	for qemu-devel@nongnu.org; Thu, 20 Jan 2011 12:12:30 -0500
Received: from mx1.redhat.com ([209.132.183.28]:62388)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1Pfy3g-0003jV-M0
	for qemu-devel@nongnu.org; Thu, 20 Jan 2011 12:12:28 -0500
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH] Fake machine for scalability testing
References: <m38vyit1ao.fsf@blackfin.pond.sub.org>
	<4D38642C.5050306@codemonkey.ws>
Date: Thu, 20 Jan 2011 18:12:14 +0100
In-Reply-To: <4D38642C.5050306@codemonkey.ws> (Anthony Liguori's message of
	"Thu, 20 Jan 2011 10:34:52 -0600")
Message-ID: <m31v47wlch.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 01/18/2011 02:16 PM, Markus Armbruster wrote:
>> The problem: you want to do serious scalability testing (1000s of VMs)
>> of your management stack.  If each guest eats up a few 100MiB and
>> competes for CPU, that requires a serious host machine.  Which you don't
>> have.  You also don't want to modify the management stack at all, if you
>> can help it.
>>
>> The solution: a perfectly normal-looking QEMU that uses minimal
>> resources.  Ability to execute any guest code is strictly optional ;)
>>
>> New option -fake-machine creates a fake machine incapable of running
>> guest code.  Completely compiled out by default, enable with configure
>> --enable-fake-machine.
>>
>> With -fake-machine, CPU use is negligible, and memory use is rather
>> modest.
>>
>> Non-fake VM running F-14 live, right after boot:
>> UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
>> armbru   15707  2558 53 191837 414388 1 21:05 pts/3    00:00:29 [...]
>>
>> Same VM -fake-machine, after similar time elapsed:
>> UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
>> armbru   15742  2558  0 85129  9412   0 21:07 pts/3    00:00:00 [...]
>>
>> We're using a very similar patch for RHEL scalability testing.
>>    
>
> Interesting, but:
>
>  9432 anthony   20   0  153m  14m 5384 S    0  0.2   0:00.22
> qemu-system-x86
>
> That's qemu-system-x86 -m 4

Sure you ran qemu-system-x86 -fake-machine?

> In terms of memory overhead, the largest source is not really going to
> be addressed by -fake-machine (l1_phys_map and phys_ram_dirty).

git-grep phys_ram_dirty finds nothing.

> I don't really understand the point of not creating a VCPU with KVM.
> Is there some type of overhead in doing that?

I briefly looked at both main loops, TCG's was the first one I happened
to crack, and I didn't feel like doing both then.  If the general
approach is okay, I'll gladly investigate how to do it with KVM.