Re: [PATCH 1/1] x86: fix text_poke

[Masami Hiramatsu <mhiramat@redhat.com>]

Jeremy Fitzhardinge wrote:
> Mathieu Desnoyers wrote:
>> * Linus Torvalds (torvalds@linux-foundation.org) wrote:
>>   
>>> On Fri, 25 Apr 2008, H. Peter Anvin wrote:
>>>     
>>>> Yes, that should work.  It's still ugly, and I have to say I find the
>>>> complexity rather distasteful.  I am willing to be convinced it's worth it,
>>>> but I would really like to see hard numbers.
>>>>       
>>> I really cannot imagine that this kind of pain is *ever* worth it. 
>>>
>>> Please give an example of something so important that we'd want to do 
>>> complex code rewriting on the fly. What _is_ the point of imv_cond()?
>>>
>>> 		Linus
>>>     
>> The point is to provide a way to dynamically enable code at runtime
>> without noticeable performance impact on the system. It's principally
>> useful to control the markers in the kernel, which can be placed in very
>> frequently executed code paths. The original markers add a memory read,
>> test and conditional branch at each marker site. By using the immediate
>> values patchset, it goes down to a load immediate value, test and branch.
>>
>> However, Ingo was still unhappy with the conditional branch, so I cooked
>> this jump patching optimization on top of the immediate values. 
> 
> I think all this demonstrates that the conditional branch is a bearable 
> cost compared to the alternative.  A conditional branch which almost 
> always branches the same way is very predictable, and really shouldn't 
> cost very much.

I agree with you.

When I measured the performance of a tracer (LKST) which used conditional
branches, the overhead of the conditional branch itself was very small
(less than 1%).
Moreover, some benchmarks showed the performance of the patched kernel
became ~1% faster than before :-) (I guessed that came from changing of
memory access pattern and timing.)

I think, if someone is considering about the actual performance impacts,
we'd better discuss the effects of the individual trace points, based
on the actual results of some benchmarks.
Thus, we can improve it step by step.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com