From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Borntraeger Subject: Re: [PATCH/RFC 2/3] s390/kvm: Platform specific kvm_arch_vcpu_dont_yield Date: Fri, 14 Feb 2014 10:55:31 +0100 Message-ID: <52FDE813.5050809@de.ibm.com> References: <1392119132-50182-1-git-send-email-borntraeger@de.ibm.com> <1392119132-50182-3-git-send-email-borntraeger@de.ibm.com> <52FD4913.3000107@redhat.com> <52FD4D17.10307@de.ibm.com> <52FD5608.2050808@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , KVM , linux-s390 , Cornelia Huck , Christian Ehrhardt To: Paolo Bonzini , Michael Mueller Return-path: Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:60933 "EHLO e06smtp17.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbaBNJzn (ORCPT ); Fri, 14 Feb 2014 04:55:43 -0500 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Feb 2014 09:55:41 -0000 In-Reply-To: <52FD5608.2050808@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 14/02/14 00:32, Paolo Bonzini wrote: > Il 13/02/2014 23:54, Christian Borntraeger ha scritto: >> We had several variants but in the end we tried to come up with a patch that does not >> influence other architectures. Your proposal would certainly be fine for s390, >> but what impact does it have on x86, arm, arm64? Will it cause performance regressions? > > It may also have the same advantages you got on s390. > >> So I think that the patch as is is probably the safest choice until we have some >> data from x86, arm, arm64, no? > > No, using an existing API is always better than inventing a new one. OK. Michael can you rework the series to simply use " if (waitqueue_active(&vcpu->wq) && !kvm_arch_vcpu_runnable(vcpu)" in kvm_vcpu_on_spin and make kvm_arch_vcpu_runnable kvm_cpu_has_interrupt(vcpu) in s390 code? That should be equivalent for s390 with even simpler code. It might also help x86 and others. > If you post the new patch series, and describe the benchmark you were using, we can reproduce it on x86. The benchmark was some workload doing lots of semaphore up/down with hundreds of processes. Will see if I can come up with a minimal test.