On Thu, 7 Mar 2019 09:45:35 -0800 Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Thu, Mar 7, 2019 at 9:38 AM Peter Zijlstra <pet...@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
