From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH RFC 1/2] KVM: don't check for PF_VCPU when yielding Date: Fri, 28 Nov 2014 11:58:01 +0100 Message-ID: <54785539.9010005@de.ibm.com> References: <1416931449-24585-1-git-send-email-dahi@linux.vnet.ibm.com> <1416931449-24585-2-git-send-email-dahi@linux.vnet.ibm.com> <54758692.5000906@de.ibm.com> <20141126102319.2f92c64b@thinkpad-w530> <54759E07.5050204@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: David Hildenbrand , KVM , Paolo Bonzini , Gleb Natapov , jfrei@linux.vnet.ibm.com, Cornelia Huck , Michael Mueller , raghavendra.kt.linux@gmail.com To: Raghavendra KT Return-path: Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:55512 "EHLO e06smtp13.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbaK1K6N (ORCPT ); Fri, 28 Nov 2014 05:58:13 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Nov 2014 10:58:11 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0350B17D8056 for ; Fri, 28 Nov 2014 10:58:25 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sASAw8qP15597568 for ; Fri, 28 Nov 2014 10:58:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sASAw349001425 for ; Fri, 28 Nov 2014 03:58:07 -0700 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Am 28.11.2014 um 11:08 schrieb Raghavendra KT: > Was able to test the patch, here is the result: I have not tested with > bigger VMs though. Results make it difficult to talk about any side > effect of > patch if any. Thanks a log. If our assumption is correct, then this patch should have no side effect on x86. Do you have any confidence guess if the numbers below mean: no-change vs. regression vs improvement? Christian > > System 16 core 32cpu (+ht) sandybridge > with 4 guests of 16vcpu each > > +-----------+-----------+-----------+------------+-----------+ > kernbench (time taken lower is better) > +-----------+-----------+-----------+------------+-----------+ > base %stdev patched %stdev %improvement > +-----------+-----------+-----------+------------+-----------+ > 1x 53.1421 2.3086 54.6671 2.9673 -2.86966 > 2x 89.6858 6.4540 94.0626 6.8317 -4.88015 > +-----------+-----------+-----------+------------+-----------+ > > +-----------+-----------+-----------+------------+-----------+ > ebizzy (recors/sec higher is better) > +-----------+-----------+-----------+------------+-----------+ > base %stdev patched %stdev %improvement > +-----------+-----------+-----------+------------+-----------+ > 1x 14523.2500 8.4388 14928.8750 3.0478 2.79294 > 2x 3338.8750 1.4592 3270.8750 2.3980 -2.03661 > +-----------+-----------+-----------+------------+-----------+ > +-----------+-----------+-----------+------------+-----------+ > dbench (Throughput higher is better) > +-----------+-----------+-----------+------------+-----------+ > base %stdev patched %stdev %improvement > +-----------+-----------+-----------+------------+-----------+ > 1x 6386.4737 1.0487 6703.9113 1.2298 4.97047 > 2x 2571.4712 1.3733 2571.8175 1.6919 0.01347 > +-----------+-----------+-----------+------------+-----------+ > > Raghu > > On Wed, Nov 26, 2014 at 3:01 PM, Christian Borntraeger > wrote: >> Am 26.11.2014 um 10:23 schrieb David Hildenbrand: >>>> This change is a trade-off. >>>> PRO: This patch would improve the case of preemption on s390. This is probably a corner case as most distros have preemption off anyway. >>>> CON: The downside is that kvm_vcpu_yield_to is called also from kvm_vcpu_on_spin. Here we want to avoid the scheduler overhead for a wrong decision. >>> >>> Won't most of that part be covered by: >>> if (!ACCESS_ONCE(vcpu->preempted)) >> >> Hmm, right. Checking vcpu->preempted and PF_VCPU might boil down to the same. >> Would be good if to have to performance regression test, though. >> >>> >>> vcpu->preempted is only set when scheduled out involuntarily. It is cleared >>> when scheduled in. s390 sets it manually, to speed up waking up a vcpu. >>> >>> So when our task is scheduled in (an PF_VCPU is set), this check will already >>> avoid scheduler overhead in kvm_vcpu_on_spin() or am I missing something? >>> >> >> CC Raghavendra KT. Could be rerun your kernbench/sysbench/ebizzy setup on x86 to see if the patch in this thread causes any regression? If think your commit 7bc7ae25b143"kvm: Iterate over only vcpus that are preempted" might have really made the PF_VCPU check unnecessary >> >> CC Michael Mueller, do we still have our yield performance setup handy to check if this patch causes any regression? >> >> >> Christian >> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >