Re: [Qemu-devel] [PATCH] qemu-kvm: introduce cpu_start/cpu_stop commands

[Avi Kivity <avi@redhat.com>]

On 11/23/2010 03:51 PM, Anthony Liguori wrote:
> On 11/23/2010 12: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.
>>>
>>> The monitor commands provide a more elegant solution that signals 
>>> because it
>>> ensures that a stopped vcpu isn't holding the qemu_mutex.
>>>
>>
>> From signal(7):
>>
>>   The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
>>
>> Perhaps this is a bug in kvm?
>
> I need to dig deeper than.

Signals are a bottomless pit.

> Maybe its something about sending SIGSTOP to a process?

AFAIK sending SIGSTOP to a process should stop all of its threads?  
SIGSTOPping a thread should also work.

>>
>> If we could catch SIGSTOP, then it would be easy to unblock it only 
>> while running in guest context. It would then stop on exit to userspace.
>
> Yeah, that's not a bad idea.

Except we can't.

>
>> Using monitor commands is fairly heavyweight for something as high 
>> frequency as this.  What control period do you see people using?  
>> Maybe we should define USR1 for vcpu start/stop.
>>
>> What happens if one vcpu is stopped while another is running?  Spin 
>> loops, synchronous IPIs will take forever.  Maybe we need to stop the 
>> entire process.
>
> It's the same problem if a VCPU is descheduled while another is running. 

We can fix that with directed yield or lock holder preemption 
prevention.  But if a vcpu is stopped by qemu, we suddenly can't.

> The problem with stopping the entire process is that a big motivation 
> for this is to ensure that benchmarks have consistent results 
> regardless of CPU capacity.  If you just monitor the full process, 
> then one VCPU may dominate the entitlement resulting in very erratic 
> benchmarking.

What's the desired behaviour?  Give each vcpu 300M cycles per second, or 
give a 2vcpu guest 600M cycles per second?

You could monitor threads separately but stop the entire process.  
Stopping individual threads will break apart as soon as they start 
taking locks.

-- 
error compiling committee.c: too many arguments to function