From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH/RFC] KVM: track pid for VCPU only on KVM_RUN ioctl Date: Wed, 20 Aug 2014 09:01:04 +0200 Message-ID: <53F447B0.1000808@de.ibm.com> References: <1407249854-2953-1-git-send-email-borntraeger@de.ibm.com> <20140818050245.GA3407@kernel> <53F35953.4000607@de.ibm.com> <20140819232246.GA8759@kernel> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , KVM , Gleb Natapov , Rik van Riel , Raghavendra K T , Michael Mueller To: Wanpeng Li Return-path: Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:55128 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750984AbaHTHBN (ORCPT ); Wed, 20 Aug 2014 03:01:13 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Aug 2014 08:01:11 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 62F942190046 for ; Wed, 20 Aug 2014 08:00:50 +0100 (BST) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s7K7170Y28835902 for ; Wed, 20 Aug 2014 07:01:07 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s7K716vF022071 for ; Wed, 20 Aug 2014 03:01:06 -0400 In-Reply-To: <20140819232246.GA8759@kernel> Sender: kvm-owner@vger.kernel.org List-ID: On 20/08/14 01:22, Wanpeng Li wrote: > On Tue, Aug 19, 2014 at 04:04:03PM +0200, Christian Borntraeger wrote: >> On 18/08/14 07:02, Wanpeng Li wrote: >>> Hi Christian, >>> On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote: >>>> We currently track the pid of the task that runs the VCPU in >>>> vcpu_load. Since we call vcpu_load for all kind of ioctls on a >>>> CPU, this causes hickups due to synchronize_rcu if one CPU is >>>> modified by another CPU or the main thread (e.g. initialization, >>>> reset). We track the pid only for the purpose of yielding, so >>>> let's update the pid only in the KVM_RUN ioctl. >>>> >>>> In addition, don't do a synchronize_rcu on startup (pid == 0). >>>> >>>> This speeds up guest boot time on s390 noticably for some configs, e.g. >>>> HZ=100, no full state tracking, 64 guest cpus 32 host cpus. >>>> >>>> Signed-off-by: Christian Borntraeger >>>> CC: Rik van Riel >>>> CC: Raghavendra K T >>>> CC: Michael Mueller >>>> --- >>>> virt/kvm/kvm_main.c | 17 +++++++++-------- >>>> 1 file changed, 9 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >>>> index 9ae9135..ebc8f54 100644 >>>> --- a/virt/kvm/kvm_main.c >>>> +++ b/virt/kvm/kvm_main.c >>>> @@ -124,14 +124,6 @@ int vcpu_load(struct kvm_vcpu *vcpu) >>>> >>>> if (mutex_lock_killable(&vcpu->mutex)) >>>> return -EINTR; >>> >>> One question: >>> >>>> - if (unlikely(vcpu->pid != current->pids[PIDTYPE_PID].pid)) { >>> >>> When vcpu->pid and current->pids[PIDTYPE_PID].pid will be different? >> >> If two different thread call an ioctl on a vcpu fd. (It must be an ioctl that has done vcpu_load - almost all except for some interrupt injections) > > Thanks for your explanation. When can this happen? In general, by using clone and do an ioctl in the new thread on a pre-existing fd. In qemu, e.g. by using an kvm_ioctl on a vcpu from main thread or another cpu.