Messages in this thread | | | Date | Mon, 28 Apr 2008 14:01:01 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 1/1] x86: fix text_poke |
| |
Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: >> And once we accept the static markers, we might as well make them as >> cheap as possible. > > Sure, so long as you take "as cheap as possible" to mean cheap in both > implementation complexity as well as runtime cost. > > I don't have any specific objections to any of the stuff that Mathieu is > working on, but it does worry me that each time a problem is addressed > it ends up being an even more subtle piece of code. I just haven't seen > enough concrete justification to make me feel comfortable with it all. > > It seems to me that a relatively simple implementation which allows the > desired tracing/marking functionality is the first step. If that proves > to cause a significant performance deficit then enabled then we can work > out how to address it in due course. But doing it all at once before > merging anything seems like overkill, particularly when we're talking > about specifics of gcc's codegen patterns, disassembling code fragments, > etc. >
I really feel that the latest information that has come up has indicated that things are really not what they should be. They are in line, have a substantial probe cost, and we're messing around with how to jump around them.
That's not the problem.
I maintain what I said before: a call instruction (which defaults to a NOP), and then extract the state based on debugging info or assembler annotations.
As far as patchable static jumps, I can see the utility of them, but I don't think this project is one of them. However, I believe the right way to do them is via compiler support.
-hpa
| |