Anthony Liguori<address@hidden> writes:
On 01/20/2011 11:12 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden> 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.