WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC V5 00/11] Paravirtualized ticketlocks
From: Jason Baron <jbaron@xxxxxxxxxx>
Date: Fri, 14 Oct 2011 14:35:39 -0400
Cc: Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, KVM <kvm@xxxxxxxxxxxxxxx>, konrad.wilk@xxxxxxxxxx, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, rth@xxxxxxxxxx, Andi Kleen <andi@xxxxxxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 14 Oct 2011 11:37:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E986B2B.60803@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <cover.1318466916.git.jeremy.fitzhardinge@xxxxxxxxxx> <1318503245.24856.12.camel@twins> <4E971580.6030300@xxxxxxxx> <20111014141701.GA2433@xxxxxxxxxx> <4E986B2B.60803@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-12-10)
On Fri, Oct 14, 2011 at 10:02:35AM -0700, Jeremy Fitzhardinge wrote:
> On 10/14/2011 07:17 AM, Jason Baron wrote:
> > On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
> >> pvops is basically a collection of ordinary _ops structures full of
> >> function pointers, but it has a layer of patching to help optimise it. 
> >> In the common case, this just replaces an indirect call with a direct
> >> one, but in some special cases it can inline code.  This is used for
> >> small, extremely performance-critical things like cli/sti, but it
> >> awkward to use in general because you have to specify the inlined code
> >> as a parameterless asm.
> >>
> > I haven't look at the pvops patching (probably should), but I was
> > wondering if jump labels could be used for it? Or is there something
> > that the pvops patching is doing that jump labels can't handle?
> 
> Jump labels are essentially binary: you can use path A or path B.  pvops
> are multiway: there's no limit to the number of potential number of
> paravirtualized hypervisor implementations.  At the moment we have 4:
> native, Xen, KVM and lguest.
> 

Yes, they are binary using the static_branch() interface. But in
general, the asm goto() construct, allows branching to any number of
labels. I have implemented the boolean static_branch() b/c it seems like
the most common interface for jump labels, but I imagine we will
introduce new interfaces as time goes on. You could of course nest
static_branch() calls, although I can't say I've tried it.

We could have an interface, that allowed static branch(), to specifiy an
arbitrary number of no-ops such that call-site itself could look anyway
we want, if we don't know the bias at compile time. This, of course
means potentially greater than 1 no-op in the fast path. I assume the
pvops can have greater than 1 no-op in the fast path. Or is there a
better solution here?

> As I said, pvops patching is very general since it allows a particular
> op site to be either patched with a direct call/jump to the target code,
> or have code inserted inline at the site.  In fact, it probably wouldn't
> take very much to allow it to implement jump labels.
> 
> And the pvops patching mechanism is certainly general to any *ops style
> structure which is initialized once (or rarely) and could be optimised. 
> LSM, perhaps?
> 
> >> Jump_labels is basically an efficient way of doing conditionals
> >> predicated on rarely-changed booleans - so it's similar to pvops in that
> >> it is effectively a very ordinary C construct optimised by dynamic code
> >> patching.
> >>
> > Another thing is that it can be changed at run-time...Can pvops be
> > adjusted at run-time as opposed to just boot-time?
> 
> No.  In general that wouldn't really make sense, because once you've
> booted on one hypervisor you're stuck there (though hypothetically you
> could consider migration between machines with different hypervisors). 
> In some cases it might make sense though, such as switching on PV
> ticketlocks if the host system becomes overcommitted, but leaving the
> native ticketlocks enabled if not.
> 
>     J

A nice featuer of jump labels, is that it allows the various branches
(currently we only support 2), to be written in c code (as opposed to asm),
which means you can write your code as you normally would and access any
parameters as you normally would - hopefully, making the code pretty
readable as well.

I hope this better clarifies the use-cases for the various mechanisms.

Thanks,

-Jason

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>