On 01/20/2011 05:27 PM, Marcelo Tosatti wrote:
> Before patch:
>
> real 5m6.493s
> user 3m57.847s
> sys 9m7.115s
>
> real 5m1.750s
> user 4m0.109s
> sys 9m10.192s
>
>
> After patch:
> real 5m0.140s
> user 3m57.956s
> sys 8m58.339s
>
> real 4m56.314s
> user 4m0.303s
> sys 8m55.774s
Nice. One disadvantageous side effect for the kvm_vcpu_kick path
is that it can race with make_all_cpus_request, which is possibly
doing unrelated, slower work (IPI'ing other vcpus, waiting for
response).
I think we're fine here. The kvm_vcpu_kick() check is
me = get_cpu();
if (cpu != me&& (unsigned)cpu< nr_cpu_ids&& cpu_online(cpu))
- if (atomic_xchg(&vcpu->guest_mode, 0))
+ if (kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE)
smp_send_reschedule(cpu);
put_cpu();
even if it did race, ->mode becomes EXITING_GUEST_MODE and we still
avoid the IPI. Note that make_all_cpus_request() cleverly checks for !=
OUTSIDE_GUEST_MODE, so if it loses the race with kvm_vcpu_kick(), it
still sends the IPI to be sure the vcpu loop sees vcpu->requests in time.
Looks ok, but lets wait for more careful reviews before applying.
Patches applied.
--
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
