From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC] KVM: optimize the kvm_vcpu_on_spin Date: Mon, 31 Jul 2017 16:23:55 +0200 Message-ID: References: <1501309377-195256-1-git-send-email-longpeng2@huawei.com> <85acc922-2b76-3e52-1f77-c200949b0532@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: agraf@suse.com, borntraeger@de.ibm.com, cohuck@redhat.com, christoffer.dall@linaro.org, james.hogan@imgtec.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, weidong.huang@huawei.com, arei.gonglei@huawei.com, wangxinxin.wang@huawei.com, longpeng.mike@gmail.com To: Marc Zyngier , "Longpeng(Mike)" , rkrcmar@redhat.com Return-path: In-Reply-To: <85acc922-2b76-3e52-1f77-c200949b0532@arm.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 31/07/2017 15:42, Marc Zyngier wrote: >> If the vcpu(me) exit due to request a usermode spinlock, then >> the spinlock-holder may be preempted in usermode or kernmode. >> But if the vcpu(me) is in kernmode, then the holder must be >> preempted in kernmode, so we should choose a vcpu in kernmode >> as the most eligible candidate. > > That seems to preclude any form of locking between userspace and kernel > (which probably wouldn't be Linux). Are you sure that this form of > construct is not used anywhere? I have the feeling this patch could > break this scenario... It's just a heuristic; it would only be broken if you overcommit, and it would be just as broken as if KVM didn't implement directed yield at all. Paolo