Gregory Haskins wrote:
> Out of curiosity, did you review my kick_process() version or the newer
> smp_call_function_single() based version of the patch?
>
>
The former.
>>
>>> @@ -1866,6 +1874,19 @@ static int kvm_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>>>
>> struct kvm_run *kvm_run)
>>
>>> kvm_arch_ops->decache_regs(vcpu);
>>> }
>>>
>>> + /*
>>> + * Make sure the current task is accurately recorded. Most of the
>>> + * time, it will be so we first check if its necessary without taking
>>> + * the lock. If there is a mismatch, we must aquire the lock and
>>> + * check again to eliminate races
>>> + */
>>> + if (unlikely(vcpu->irq.task != current)) {
>>> + spin_lock(&vcpu->irq.lock);
>>> + if (vcpu->irq.task != current)
>>> + vcpu->irq.task = current;
>>> + spin_unlock(&vcpu->irq.lock);
>>> + }
>>> +
>>>
>>>
>> Isn't this equivalent to
>>
>> vcpu->irq.task = current
>>
>
> Yeah, good point. I originally had a printk in there to report when it
> changes, thus the conditional. I didn't collapse it when I took the printk
> out. I suppose you could argue that updating the variable indiscriminately
> will unnecessarily dirty a cache-line, but I doubt it would matter in the
> grand scheme of things.
>
>
The vcpu cachelines are already dirty.
Please repost the patchset (one patch per message) so I can see it
together. Thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
