Re: [PATCH] qemu-kvm: Consolidate kvm_eat_signals

[Avi Kivity <avi@qumranet.com>]

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
>> returning immediately with -EINTR (i.e. in the outer loop).
>>
>>     
>
> You mean
>
> static void kvm_main_loop_wait(CPUState *env, int timeout)
> {
>     pthread_mutex_unlock(&qemu_mutex);
>     kvm_eat_signal(env, timeout);
>     pthread_mutex_lock(&qemu_mutex);
>     cpu_single_env = env;
>
>     vcpu_info[env->cpu_index].signalled = 0;
> }
>
> ?
>   

Yes.  The loop was a (perhaps premature) optimization that is now 
totally unnecessary, unless I'm missing something quite large.

Oh.  There used to be a bug where we didn't check for a pending signal 
before the first guest entry, so this would add a lot of latency 
(effectively making the bug window much larger).  That was only closed 
in 2.6.24 (by 7e66f350).

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


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone