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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
