From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH RFC V2 5/5] kvm guest : pv-ticketlocks support for linux guests running on KVM hypervisor Date: Wed, 26 Oct 2011 12:46:15 -0700 Message-ID: <4EA86387.5040108@goop.org> References: <20111023190307.16364.35381.sendpatchset@oc5400248562.ibm.com> <20111023190753.16364.31164.sendpatchset@oc5400248562.ibm.com> <4EA7012B.5040808@goop.org> <4EA85E32.3080107@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Raghavendra K T , Greg Kroah-Hartman , "H. Peter Anvin" , Gleb Natapov , Virtualization , "x86@kernel.org" , KVM , Dave Jiang , Thomas Gleixner , Stefano Stabellini , Yinghai Lu , Sedat Dilek , Ingo Molnar , Marcelo Tosatti , Xen , Avi Kivity , Rik van Riel , Konrad Rzeszutek Wilk , LKML , Suzuki Poulose , Srivatsa Vaddagiri , Peter Zijlstra To: Raghavendra K T Return-path: In-Reply-To: <4EA85E32.3080107@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 10/26/2011 12:23 PM, Raghavendra K T wrote: > On 10/26/2011 12:04 AM, Jeremy Fitzhardinge wrote: >> On 10/23/2011 12:07 PM, Raghavendra K T wrote: >>> This patch extends Linux guests running on KVM hypervisor to support >>> +/* >>> + * Setup pv_lock_ops to exploit KVM_FEATURE_WAIT_FOR_KICK if present. >>> + * This needs to be setup really early in boot, before the first >>> call to >>> + * spinlock is issued! >> >> Actually, it doesn't matter that much. The in-memory format is the same >> for regular and PV spinlocks, and the PV paths only come into play if >> the "slowpath" flag is set in the lock, which it never will be by the >> non-PV code. >> >> In principle, you could defer initializing PV ticketlocks until some >> arbitrarily late point if you notice that the system is oversubscribed >> enough to require it. > > ok.. so this means it will not affect even if it is initialized in > middle somewhere, but better to do it before we start seeing lock > contention. Right. Or more specifically, lock contention while you have VCPU overcommit. > our current aim was to have before any printk happens. > So I 'll trim the comment to somethings like : > > Setup pv_lock_ops to exploit KVM_FEATURE_WAIT_FOR_KICK if present. > This needs to be setup early in boot. ? You can hook the smp_ops.smp_prepare_cpus call and initialize it there. There's no need to add new hook code. J