Re: [Qemu-devel] [RFC PATCH] Fake machine for scalability testing

[Markus Armbruster]

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.

If you think we can achieve my goals (stated in my first paragraph) in a
different way, I'm all ears.