Messages in this thread |  | | Date | Wed, 31 Jan 2007 13:04:36 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH 4/5] KVM: cpu hotplug support |
| |
Ingo Molnar wrote: > * Andrew Morton <akpm@osdl.org> wrote: > > >> On Tue, 30 Jan 2007 14:56:16 -0000 >> Avi Kivity <avi@qumranet.com> wrote: >> >> >>> +static void decache_vcpus_on_cpu(int cpu) >>> +{ >>> + struct kvm *vm; >>> + struct kvm_vcpu *vcpu; >>> + int i; >>> + >>> + spin_lock(&kvm_lock); >>> + list_for_each_entry(vm, &vm_list, vm_list) >>> + for (i = 0; i < KVM_MAX_VCPUS; ++i) { >>> + vcpu = &vm->vcpus[i]; >>> + /* >>> + * If the vcpu is locked, then it is running on some >>> + * other cpu and therefore it is not cached on the >>> + * cpu in question. >>> + * >>> + * If it's not locked, check the last cpu it executed >>> + * on. >>> + */ >>> + if (mutex_trylock(&vcpu->mutex)) { >>> + if (vcpu->cpu == cpu) { >>> + kvm_arch_ops->vcpu_decache(vcpu); >>> + vcpu->cpu = -1; >>> + } >>> + mutex_unlock(&vcpu->mutex); >>> + } >>> + } >>> + spin_unlock(&kvm_lock); >>> +} >>> >> The trylock is unpleasing. Perhaps kvm_lock should be a mutex or >> something? >> > > this is a special case. The vcpu->mutex acts as a 'this vcpu is running > right now' flag as well - hence the trylock signals: is it running right > now or not - if it's not running we do not have to 'decache' it. But i > agree and i already suggested to Avi to change kvm_lock to be a mutex - > but this wont change the trylock. >
To elaborate a little: replacing mutex_trylock() with mutex_lock() will cause unbounded latency as we wait for the vcpu to be descheduled. In this case, we're only interested in descheduled vcpus, so there's no need to wait.
kvm is a bit funny in how it likes to pin cpus.
-- error compiling committee.c: too many arguments to function
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |