[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190419090440.640a46c2@gandalf.local.home>
Date: Fri, 19 Apr 2019 09:04:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Anvin <hpa@...or.com>,
Julien Thierry <julien.thierry@....com>,
Will Deacon <will.deacon@....com>,
Andy Lutomirski <luto@...capital.net>,
Catalin Marinas <catalin.marinas@....com>,
James Morse <james.morse@....com>, valentin.schneider@....com,
Brian Gerst <brgerst@...il.com>,
Andrew Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Denys Vlasenko <dvlasenk@...hat.com>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
Slavomir Kaslev <kaslevs@...are.com>
Subject: Re: [PATCH] compiler.h, tracing: Remove CONFIG_PROFILE_ALL_BRANCHES
On Fri, 19 Apr 2019 12:08:37 +0200
Ingo Molnar <mingo@...nel.org> 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:
http://rostedt.homelinux.com/branches/gandalf-branches-2019/brach_all-2019-02-05
http://rostedt.homelinux.com/branches/mammoth-branches-2019/branch_all-2019-01-02
http://rostedt.homelinux.com/branches/mammoth-branches-2019/branch_all-2019-01-03
http://rostedt.homelinux.com/branches/mammoth-branches-2019/branch_all-2019-01-17
http://rostedt.homelinux.com/branches/mammoth-branches-2019/branch_all-2019-02-05
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ā¢.
Powered by blists - more mailing lists