From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header
Date: Thu, 4 Jun 2020 10:19:28 +0200 [thread overview]
Message-ID: <20200604081928.GA570386@gmail.com> (raw)
In-Reply-To: <20200604071921.GA1361070@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Mon, Jun 1, 2020 at 6:08 AM Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > include/linux/compiler.h | 53 +++++++++++++++++++++++
> >
> > I have pulled this, but do we really want to add this to a header file
> > that is _so_ core that it gets included for basically every single
> > file built?
> >
> > I don't even see those instrumentation_begin/end() things used
> > anywhere right now.
> >
> > It seems excessive. That 53 lines is maybe not a lot, but it pushed
> > that header file to over 12kB, and while it's mostly comments, it's
> > extra IO and parsing basically for _every_ single file compiled in the
> > kernel.
> >
> > For what appears to be absolutely zero upside right now, and I really
> > don't see why this should be in such a core header file!
> >
> > I don't even see this as having anything at all to do with
> > "compiler.h" in the first place.
> >
> > I really think we should think twice about making core header files
> > bigger like this. No, we're nowhere the disaster that C++ project
> > headers are, but tokenization and parsing is actually a pretty big
> > part of the build costs (which may surprise some people who think it's
> > all the fancy optimizations that cost a lot of CPU time).
>
> Fully agreed - and I made the attached patch to address this.
>
> The code got cleaner and better structured, but it didn't help much in
> terms of inclusion count:
>
> 2616 total .o files
>
> 2447 <linux/types.h>
> 2436 <linux/compiler.h>
> 2404 <linux/bug.h>
>
> The reason is that <linux/bug.h> is included almost everywhere as
> well, and the instrumentation_begin()/end() annotations affect the
> BUG*() and WARN*() primitives as well.
>
> At least non-x86 would have less instrumentation related noise, for
> now at least.
> arch/x86/include/asm/bug.h | 1 +
> include/linux/compiler.h | 53 -------------------------------------
> include/linux/context_tracking.h | 2 ++
> include/linux/instrumentation.h | 57 ++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 60 insertions(+), 53 deletions(-)
The tested v2 version of the patch also needed the include in
asm-generic/bug.h (see the fix attached below), because for
completeness the generic version was annotated as well - even though
only x86 has objtool support for now.
The readability improvement is real though.
Thanks,
Ingo
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 384b5c835ced..c43b5906e0dc 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -3,6 +3,7 @@
#define _ASM_GENERIC_BUG_H
#include <linux/compiler.h>
+#include <linux/instrumentation.h>
#define CUT_HERE "------------[ cut here ]------------\n"
next prev parent reply other threads:[~2020-06-04 8:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 13:08 [GIT PULL] kprobes updates for v5.8 Ingo Molnar
2020-06-01 19:56 ` Linus Torvalds
2020-06-04 7:19 ` [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header Ingo Molnar
2020-06-04 8:19 ` Ingo Molnar [this message]
2020-06-04 9:38 ` Peter Zijlstra
2020-06-05 14:35 ` Ingo Molnar
2020-07-24 12:02 ` [tip: core/headers] compiler.h: Move instrumentation_begin()/end() to " tip-bot2 for Ingo Molnar
2020-06-01 21:55 ` [GIT PULL] kprobes updates for v5.8 pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200604081928.GA570386@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome