From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55011 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PgIF2-00051O-2P for qemu-devel@nongnu.org; Fri, 21 Jan 2011 09:45:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PgIF0-0003Lh-BG for qemu-devel@nongnu.org; Fri, 21 Jan 2011 09:45:31 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:62740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PgIF0-0003LY-8q for qemu-devel@nongnu.org; Fri, 21 Jan 2011 09:45:30 -0500 Received: by qwk4 with SMTP id 4so1853949qwk.4 for ; Fri, 21 Jan 2011 06:45:29 -0800 (PST) Message-ID: <4D399C0A.4080107@codemonkey.ws> Date: Fri, 21 Jan 2011 08:45:30 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH] Fake machine for scalability testing References: <4D38642C.5050306@codemonkey.ws> <4D389209.8070202@codemonkey.ws> In-Reply-To: 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: Markus Armbruster Cc: qemu-devel@nongnu.org On 01/21/2011 04:38 AM, Markus Armbruster wrote: > Anthony Liguori writes: > > >> On 01/20/2011 11:12 AM, Markus Armbruster wrote: >> >>> Anthony Liguori 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? >>> >>> >> No, I didn't try it. My point was that -m 4 is already pretty small. >> > Ah! > > However, it's not as small as -fake-machine, and eats all the CPU it can > get. > > None-fake VM as above, but with -m 4: > UID PID PPID C SZ RSS PSR STIME TTY TIME CMD > armbru 19325 2558 93 39869 17020 1 11:30 pts/3 00:00:42 [...] > > And I believe we can make -fake-machine use even less memory than now, > with a little more work. > > >>>> 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. >>> >>> >> Yeah, it's now ram_list[i].phys_dirty. >> >> l1_phys_map is (sizeof(void *) + sizeof(PhysPageDesc)) * mem_size_in_pages >> >> phys_dirty is mem_size_in_pages bytes. >> > Thanks. > > >>>> 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. >>> >>> >> I guess what I don't understand is why do you need to not run guest >> code? Specifically, if you remove the following, is it any less >> useful? >> >> diff --git a/cpu-exec.c b/cpu-exec.c >> index 8c9fb8b..cd1259a 100644 >> --- a/cpu-exec.c >> +++ b/cpu-exec.c >> @@ -230,7 +230,7 @@ int cpu_exec(CPUState *env1) >> uint8_t *tc_ptr; >> unsigned long next_tb; >> >> - if (cpu_halted(env1) == EXCP_HALTED) >> + if (fake_machine || cpu_halted(env1) == EXCP_HALTED) >> >> return EXCP_HALTED; >> > I don't want 1000s of guests running infinite "not enough memory to do > anything useful, panic!" reboot loops. Because that's 1000s of guests > competing for CPU. > Hrm, that's not the behavior I see. With no bootable drive, the BIOS will spin in a HLT loop as part of int18. Regards, Anthony Liguori > If you think we can achieve my goals (stated in my first paragraph) in a > different way, I'm all ears. > >