[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703191138430.6730@woody.linux-foundation.org>
Date: Mon, 19 Mar 2007 11:44:42 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
cc: Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@....de>,
David Miller <davem@...emloft.net>, jeremy@...p.org,
mingo@...e.hu, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org,
xen-devel@...ts.xensource.com, chrisw@...s-sol.org,
zach@...are.com, anthony@...emonkey.ws, netdev@...r.kernel.org
Subject: Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops
callsites to make them patchable
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".
Linus
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists