From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 5/8] KVM: use jump label to optimize checking for HW enabled APIC in APIC_BASE MSR. Date: Sun, 5 Aug 2012 17:55:38 +0300 Message-ID: <20120805145538.GS27579@redhat.com> References: <1344171513-4659-1-git-send-email-gleb@redhat.com> <1344171513-4659-6-git-send-email-gleb@redhat.com> <501E84A9.8040803@redhat.com> <20120805144223.GP27579@redhat.com> <501E87CA.8020302@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, mtosatti@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19926 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754554Ab2HEOzj (ORCPT ); Sun, 5 Aug 2012 10:55:39 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q75EtdXA015696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Aug 2012 10:55:39 -0400 Content-Disposition: inline In-Reply-To: <501E87CA.8020302@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Aug 05, 2012 at 05:48:42PM +0300, Avi Kivity wrote: > On 08/05/2012 05:42 PM, Gleb Natapov wrote: > > On Sun, Aug 05, 2012 at 05:35:21PM +0300, Avi Kivity wrote: > >> On 08/05/2012 03:58 PM, Gleb Natapov wrote: > >> > Usually all APICs are HW enabled so the check can be optimized out. > >> > > >> > Signed-off-by: Gleb Natapov > >> > --- > >> > arch/x86/kvm/lapic.c | 29 ++++++++++++++++++++++++++++- > >> > arch/x86/kvm/lapic.h | 1 + > >> > arch/x86/kvm/x86.c | 1 + > >> > 3 files changed, 30 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > >> > index c3f14fe..1aa5528 100644 > >> > --- a/arch/x86/kvm/lapic.c > >> > +++ b/arch/x86/kvm/lapic.c > >> > @@ -34,6 +34,7 @@ > >> > #include > >> > #include > >> > #include > >> > +#include > >> > #include "kvm_cache_regs.h" > >> > #include "irq.h" > >> > #include "trace.h" > >> > @@ -117,9 +118,13 @@ static inline int __apic_test_and_clear_vector(int vec, void *bitmap) > >> > return __test_and_clear_bit(VEC_POS(vec), (bitmap) + REG_POS(vec)); > >> > } > >> > > >> > +struct static_key_deferred apic_hw_disabled __read_mostly; > >> > >> On top of file please. Add all_ to the name to make it clear we're > >> talking about all apics. > >> > > This is count of disabled apics really. So I think all_apic_hw_disabled > > is misleading. > > > >> > + > >> > static inline int apic_hw_enabled(struct kvm_lapic *apic) > >> > { > >> > - return (apic)->vcpu->arch.apic_base & MSR_IA32_APICBASE_ENABLE; > >> > + if (static_key_false(&apic_hw_disabled.key)) > >> > + return apic->vcpu->arch.apic_base & MSR_IA32_APICBASE_ENABLE; > >> > >> Hm, for the test to be readable, it needs to be > >> > >> if (static_key_false(&all_apics_hw_enabled)) > >> > > Exactly. all_ makes it so because apic_hw_disabled is a counter that > > counts disabled apics. So may be call it global_hw_disabled_apic_counter? > > > > The problem is how static_key_false() is defined. It returns true if > the count > 0, opposite from what I'd expect. So anything with counter > semantics will be confusing. I guess we need to pick a neutral name > (apic_disabled_key or apic_disabled_slowpath or such) to force the > reader to look at the definitions. > There was a long thread about readability of static_key_true/false and this is the result of it :( I read it this way: drop static_key_(true|false) and read the if() to understand its meaning. Now look at static_key_(true|false) to see what fast path will be in asm code. -- Gleb.