Re: [PATCH 00/20] objtool: UACCESS validation v3

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 7 Mar 2019 09:45:35 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Mar 7, 2019 at 9:38 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Also; it seems to me that something PT, or maybe even simply:
> >
> >   perf -e branches -e branch-misses
> >
> > would get you similar or sufficient information.  
> 
> Yeah, I'm not really seeing a lot of upside to PROFILE_ALL_BRANCHES.
> 
> Particularly since it doesn't actually profile all branches at all. It
> only basically profiles "if ()" statements, which obviously misses
> loops etc, but then also _does_ hit things where people turned loops
> into "if (unlikely()) loop()", which happens in (for example)
> low-level locking code etc that often has a fast-case "first try"
> thing followed by a slow-case "ok, let's loop for it" thing.
> 
> So I think PROFILE_ALL_BRANCHES tends to have very random coverage.
> I'd love to get rid of it, because it seems so random.
>

As Josh said, I run it once a year on two production (real use)
machines for 2 to 4 weeks and collect the data to see if there are
places that can be optimized better.

I currently have one of my engineers looking at the data and may be
sending patches soon. It's basically an entry level way to get into
kernel development. Note, no patch will be sent just because of the
data from the profiling. The task is to look at and understand the
code, and see if it can be optimized (with likely/unlikely or flow
changes). It's a way to get a better understanding of the kernel in
various locations. It is by no means "profiler said this, lets change
it." All changes must be rational, and make sense. The profiler is only
used to help find those places.

The data that was run at the end of January can be found here:

 http://rostedt.homelinux.com/branches/mammoth-branches-2019/
 http://rostedt.homelinux.com/branches/gandalf-branches-2019/

-- Steve