lkml.org 
[lkml]   [2022]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mmotm 2022-02-11-15-07 uploaded (objtool: ftrace_likely_update)
On Sat, 12 Feb 2022 09:06:49 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> Yes, TRACE_BRANCH_PROFILING and PROFILE_ALL_BRANCHES are fundamentally
> broken and I have no intention of trying to fix them.
>
> The moment we pull PTI into noinstr C code this will result in insta
> boot fail.

Actually, I don't think anyone has every used the "tracers" for this, and I
will be happy to get rid of it:

void ftrace_likely_update(struct ftrace_likely_data *f, int val,
int expect, int is_constant)
{
unsigned long flags = user_access_save();

/* A constant is always correct */
if (is_constant) {
f->constant++;
val = expect;
}


------8<------
/*
* I would love to have a trace point here instead, but the
* trace point code is so inundated with unlikely and likely
* conditions that the recursive nightmare that exists is too
* much to try to get working. At least for now.
*/
trace_likely_condition(f, val, expect);
----->8-------

/* FIXME: Make this atomic! */
if (val == expect)
f->data.correct++;
else
f->data.incorrect++;

user_access_restore(flags);
}
EXPORT_SYMBOL(ftrace_likely_update);

The above with the cut lines I added.

I still use the likely and unlikely counters. Would it be possible to mark
that function as "noinstr" and still record them (I don't care if there's
races where we miss a few or add a few too many). But they have been really
affective in finding bad locations of likely and unlikely callers.

As I said. I have no problem with removing the trace portion of that code.
It was more of an academic exercise than a useful one, but the counters
are still very useful to have.

-- Steve

\
 
 \ /
  Last update: 2022-02-14 16:15    [W:0.046 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site