From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks Date: Thu, 13 Oct 2011 12:54:05 +0200 Message-ID: <1318503245.24856.12.camel@twins> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: "H. Peter Anvin" , Linus Torvalds , Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List , Nick Piggin , Avi Kivity , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Jeremy Fitzhardinge To: Jeremy Fitzhardinge Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Wed, 2011-10-12 at 17:51 -0700, Jeremy Fitzhardinge wrote: > > This is is all unnecessary complication if you're not using PV ticket > locks, it also uses the jump-label machinery to use the standard > "add"-based unlock in the non-PV case. > > if (TICKET_SLOWPATH_FLAG && > unlikely(static_branch(¶virt_ticketlocks_enabled))) { > arch_spinlock_t prev; > > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > > if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) > __ticket_unlock_slowpath(lock, prev); > } else > __add(&lock->tickets.head, TICKET_LOCK_INC, UNLOCK_LOCK_PREFIX); Not that I mind the jump_label usage, but didn't paravirt have an existing alternative() thingy to do things like this? Or is the alternative() stuff not flexible enough to express this?