[lkml]   [2019]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] compiler.h, tracing: Remove CONFIG_PROFILE_ALL_BRANCHES
On Fri, 19 Apr 2019 12:08:37 +0200
Ingo Molnar <> wrote:

> > Can't you just have those same engineers look at perf data? This seems
> > like a very expensive and convoluted way of getting something.

I haven't tried the perf data. How well does it work with running over
a 2 weeks to a month period? That's what I do yearly. Here's the
results of my last run:

I have a cron job that runs nightly that copies the current state, and
if the machine reboots, it starts a new file (which is why there's
multiple files for mammoth - it rebooted).

> So since no-one offered objections to using perf branch profiling instead
> (which method allows so much more than CONFIG_PROFILE_ALL_BRANCHES: such

I've never used it, so I have no idea if it is suitable or not.

> as profiling glibc and other user-space, or allowing to branch-profile
> the kernel is an uninstrumented form not distorted by
> CONFIG_PROFILE_ALL_BRANCHES code generation artifacts), lemme propose the
> attached patch to remove if-tracing.
> If the CONFIG_PROFILE_ALL_BRANCHES=y feature is required for anyone it
> can still be reverted privately or maintained out of tree - no need to
> burden the mainline kernel with this.

But is it a real burden? It's been in the kernel for over 10 years
with very little issue. Only when we do something drastic does it show
up, and it's usually a quick fix to get it working again.

I believe Josh even told me that it found a bug in the objtool code, so
it does still have benefit staying in the kernel even without people
using it for profiling.

Note, I'm in the middle of writing a LWN article about learning the
kernel from branch profiling and it would be a shame if it disappears
before I finish it.

-- Steve

> I've build tested this and it Looks Perfect Here™.

 \ /
  Last update: 2019-04-19 20:37    [W:0.078 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site