lkml.org 
[lkml]   [2009]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] [PATCH 1/5] function-graph/x86: replace unbalanced ret with jmp
* Steven Rostedt (rostedt@goodmis.org) wrote:
> On Tue, 2009-10-13 at 17:21 -0400, Mathieu Desnoyers wrote:
>
> > > What it was:
> > >
> > > call function
> > > function:
> > > call mcount
> > > mcount:
> > > call ftrace_entry
> >
> > Can we manage to change this call
>
> Note, that call jumps to C code.
>
> >
> > > ftrace_entry:
> > > mess up with return code of caller
> > > ret
> >
> > .. and this ret for 2 jmp instructions too ?
>
> The code is all in C, and it too calls functions. Not sure where this
> helps out any. The ret here matches their calls. Thus the prediction
> will work.
>

Oh, OK. I thought the callback was in assembly. That's a bit more work
than I thought.

> >
> > Given that we have no choice but to kill call/ret prediction logic, I
> > think it might be good to try to use this logic as little as possible
> > (by favoring jmp jmp over call/ret when the return target is invariant).
> >
> > That's just an idea, benchmarks could prove me right/wrong.
>
> I don't see how this would help. And I'm not about to waste time
> experimenting. What's the rational?
>

The idea is that call/ret are fast when predictions are right. In this
case, I wonder if the fact that we trash the call/ret prediction (even
if this happens after the paired call/ret) would have an impact on
balanced call/ret in the tracing code path. I doubt so, but who knows.

Probably not worth spending much time on this. It would just have been
nice to try if the implementation would have been trivial.

Thanks,

Mathieu

> -- Steve
>
>

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


\
 
 \ /
  Last update: 2009-10-14 00:47    [W:0.214 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site