2012/2/7 Takuya Yoshikawa <yoshikawa.takuya@xxxxxxxxxxxxx>:
> (2012/02/07 11:34), Liu Ping Fan wrote:
>
>> static int kvm_vcpu_release(struct inode *inode, struct file *filp)
>
> Is this a hot path?
> If no, do you really need to pre-allocate the space for the next vcpus?
>
No, it is not a hot path, I will try your way in next version.
>> {
>> + int i;
>> struct kvm_vcpu *vcpu = filp->private_data;
>> + struct kvm *kvm = vcpu->kvm;
>> + struct kvm_vcpu *vcpus_next;
>> + filp->private_data = NULL;
>> +
>> + for (i = 0; i< atomic_read(&kvm->online_vcpus); i++) {
>> + if (vcpu == kvm->vcpus+i)
>> + break;
>> + }
>> + mutex_lock(&kvm->lock);
>> + vcpus_next = kvm->vcpus_array +
>> + ((kvm->vcpus - kvm->vcpus_array) ? 0 : KVM_MAX_VCPUS);
>> +
>> + memset(vcpus_next, 0, KVM_MAX_VCPUS*sizeof(struct kvm_vcpu *));
>> + memcpy(vcpus_next, kvm->vcpus, i*sizeof(struct kvm_vcpu *));
>> + memcpy(vcpus_next+i, kvm->vcpus+i+1,
>> + (atomic_read(&kvm->online_vcpus)-i)*sizeof(struct kvm_vcpu *));
>> + atomic_dec(&kvm->online_vcpus);
>> + /* Removed vcpu can not be seen from vcpus[] */
>
> This comment is confusing.
>
I mean after assigning pointer, vcpu which to be removed can not be
seen from vcpus[]. I will fix this comment.
>> + rcu_assign_pointer(kvm->vcpus, vcpus_next);
>> + mutex_unlock(&kvm->lock);
>> +
>> + synchronize_rcu();
>>
>> - kvm_put_kvm(vcpu->kvm);
>> + /* vcpu is out of list,drop it safely */
>
> Ditto.
>
> Do you mean something like
> "now that there is no reader of it we can safely free this" ?
>
Yes, that is exactly what I mean
Thanks and regards,
ping fan
> (Please do not trust me: I am not a native English speaker as you know.)
>
>> + kvm_vcpu_destruct(vcpu);
>> return 0;
>> }
>
>
> Takuya
--
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
