From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 00/13] [PATCH RFC] Paravirtualized ticketlocks Date: Fri, 02 Sep 2011 14:42:21 -0700 Message-ID: <4E614DBD.3000504@goop.org> References: <4E61377B.4020600@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: kvm-owner@vger.kernel.org To: Linus Torvalds Cc: "H. Peter Anvin" , Peter Zijlstra , Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List , Nick Piggin , Avi Kivity , Marcelo Tosatti , KVM , Andi Kleen , Xen Devel , Jeremy Fitzhardinge List-Id: xen-devel@lists.xenproject.org On 09/02/2011 01:27 PM, Linus Torvalds wrote: > On Fri, Sep 2, 2011 at 1:07 PM, Jeremy Fitzhardinge wrote: >> I don't know whether that fastpath code is small enough to consider >> inlining everywhere? > No. > > There's no point in inlining something that ends up containing a > conditional function call: gcc will have to effectively save/restore > registers around that thing anyway, so you lose a lot of the > advantages of inlining. So I think it's better done as an out-of-line > function, which I thought we did for spinlocks anyway. Yes, lock currently out-of-line. I should also make sure that unlock is also out of line when paravirtualized. > Also, do you run with CONFIG_OPTIMIZE_SIZE? Without that, gcc should > be smart enough to make a "likely()" case be a fall-through. Ah, I was wondering why I'd never seen likely/unlikely do anything useful. With OPTIMIZE_SIZE=n, there's no point in explicitly moving the slowpath out to a separate function. So the only downside with this variant is that it breaks my design criteria of making the generated code look identical to the the original code when CONFIG_PARAVIRT_SPINLOCKS=n. But I don't know if that's an actual downside in practice. J