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/
Home Products Support Community News


[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravi

To: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Mar 2007 11:44:42 -0700 (PDT)
Cc: zach@xxxxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, anthony@xxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, chrisw@xxxxxxxxxxxx, Andi Kleen <ak@xxxxxx>, mingo@xxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxxxxx>
Delivery-date: Tue, 20 Mar 2007 02:27:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0703191134190.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070316.023331.59468179.davem@xxxxxxxxxxxxx> <45FB005D.9060809@xxxxxxxx> <1174127638.8897.75.camel@xxxxxxxxxxxxxxxxxxxxx> <20070318.003309.71088169.davem@xxxxxxxxxxxxx> <20070318120814.GA45869@xxxxxx> <1174272469.11680.23.camel@xxxxxxxxxxxxxxxxxxxxx> <m1648xxf93.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0703191134190.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Mon, 19 Mar 2007, Linus Torvalds wrote:
> So *please* don't believe that you can make it "as cheap" to have some 
> automatic fixup of two sequences, one inlined and one as a "call".  It may 
> look so when you look at the single instruction generated, but you're 
> ignoring all the instructions *around* the site.

Side note, you can certainly fix things like this at least in theory, but 
it requires:

 - the "call" instruction that is used instead of the inlining should 
   basically have no callee-clobbers. Any paravirt_ops called this way
   should have a special calling sequence where they simple save and 
   restore all the registers they use.

   This is usually not that bad. Just create a per-architecture wrapper 
   function that saves/restores anything that the C calling convention on 
   that architecture says is clobbered by calls.

 - if the function has arguments, and the inlined sequence can take the 
   arguments in arbitrary registers, you are going to penalize the inlined 
   sequence anyway (by forcing some fixed arbitrary register allocation 
   policy).This thing is largely unfixable without some really extreme 
   compiler games (like post-processing the assembler output and having 
   different entry-points depending on where the arguments are..)

.. it will obviously depend on how thngs are done whether these things are 
useful or not. But it does mean that it's always a good idea to just have 
a config option of "turn off all the paravirt crap, because it *does* add 
overhead, and replacing instructions on the fly doesn't make that 
overhead go away".


Xen-devel mailing list

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