Jeremy Fitzhardinge wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/