All of lore.kernel.org
 help / color / mirror / Atom feed
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"
 


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.