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

[Avi Kivity]

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