Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 11 ---
1 file changed, 4
Avi Kivity wrote:
Jan Kiszka wrote:
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Given that with the iothread we spend very little time
Jan Kiszka wrote:
Given that with the iothread we spend very little time processing
signals in vcpu threads, maybe it's better to drop the loop completely.
The common case is zero or one pending signals. The uncommon case of
two or more pending signals will be handled by the KVM_RUN ioctl
Avi Kivity wrote:
Jan Kiszka wrote:
Given that with the iothread we spend very little time processing
signals in vcpu threads, maybe it's better to drop the loop completely.
The common case is zero or one pending signals. The uncommon case of
two or more pending signals will be handled
Avi Kivity wrote:
Now the VCPU threads never select so the whole loop can be simplified
to a single sigtimedwait() that always blocks.
In reality, I don't think sigtimedwait() is really needed/useful for
VCPUs anymore. We only use it to catch SIG_IPI and we only use
SIG_IPI to break out
Anthony Liguori wrote:
Yes. The loop was a (perhaps premature) optimization that is now
totally unnecessary, unless I'm missing something quite large.
It used to be that kvm_eat_signal() selected after consuming as many
signals as possible while only sleeping once. That's why there's
