From: Petr Mladek <pmladek@suse.com>
To: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Russell King <linux@arm.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Aaron Tomlin <atomlin@redhat.com>, Ingo Molnar <mingo@redhat.com>,
Andrew Morton <akpm@osdl.org>,
Daniel Thompson <daniel.thompson@linaro.org>,
x86@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Tue, 16 Aug 2016 10:04:01 +0200 [thread overview]
Message-ID: <20160816080401.GJ13300@pathway.suse.cz> (raw)
In-Reply-To: <12bc082c-067b-2b85-6c17-ff0a6c011add@mellanox.com>
On Mon 2016-08-15 12:41:54, Chris Metcalf wrote:
> On 8/11/2016 11:25 AM, Petr Mladek wrote:
> >On Mon 2016-08-08 12:03:38, Chris Metcalf wrote:
> >>>>When doing an nmi backtrace of many cores, most of which are idle,
> >>>>the output is a little overwhelming and very uninformative. Suppress
> >>>>messages for cpus that are idling when they are interrupted and just
> >>>>emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
> >Hmm, the problem is that native_safe_halt() is called from default_idle()
> >here. The function is marked as inline but the compiler did not inline
> >it.
> >
> >It helped me to put native_safe_halt() into the __cpuidle_text section:
>
> Following Peter Z's suggestion, I have added an __always_inline marker
> to native_safe_halt. For consistency, I also did arch_safe_halt(), since that
> invokes native_safe_halt, and then also native_halt() and halt(), so that
> we're not being weirdly inconsistent with markings for halt inlines.
>
> There are also the native_irq_enable(), etc., accessors in that same header
> that are still only marked "inline" not "always_inline", but I wanted to stop
> before I was touching too much unrelated code.
Sounds fine.
> >I wonder if it would be possible to detect the idle thread an other
> >way. For example, I wonder if it would be enough to check for the
> >PID 0.
>
> No, the problem is that pid 0 can also go off and run "interesting" code
> for things like power management, etc., so we really just want to
> focus on being quite sure that the running code isn't interesting before
> we suppress the backtrace information.
>
> See the thread around here:
>
> https://lkml.kernel.org/r/20160307204317.GR6344@twins.programming.kicks-ass.net
Makes sense. Thanks for the poitner.
Best Regards,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: pmladek@suse.com (Petr Mladek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Tue, 16 Aug 2016 10:04:01 +0200 [thread overview]
Message-ID: <20160816080401.GJ13300@pathway.suse.cz> (raw)
In-Reply-To: <12bc082c-067b-2b85-6c17-ff0a6c011add@mellanox.com>
On Mon 2016-08-15 12:41:54, Chris Metcalf wrote:
> On 8/11/2016 11:25 AM, Petr Mladek wrote:
> >On Mon 2016-08-08 12:03:38, Chris Metcalf wrote:
> >>>>When doing an nmi backtrace of many cores, most of which are idle,
> >>>>the output is a little overwhelming and very uninformative. Suppress
> >>>>messages for cpus that are idling when they are interrupted and just
> >>>>emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".
> >Hmm, the problem is that native_safe_halt() is called from default_idle()
> >here. The function is marked as inline but the compiler did not inline
> >it.
> >
> >It helped me to put native_safe_halt() into the __cpuidle_text section:
>
> Following Peter Z's suggestion, I have added an __always_inline marker
> to native_safe_halt. For consistency, I also did arch_safe_halt(), since that
> invokes native_safe_halt, and then also native_halt() and halt(), so that
> we're not being weirdly inconsistent with markings for halt inlines.
>
> There are also the native_irq_enable(), etc., accessors in that same header
> that are still only marked "inline" not "always_inline", but I wanted to stop
> before I was touching too much unrelated code.
Sounds fine.
> >I wonder if it would be possible to detect the idle thread an other
> >way. For example, I wonder if it would be enough to check for the
> >PID 0.
>
> No, the problem is that pid 0 can also go off and run "interesting" code
> for things like power management, etc., so we really just want to
> focus on being quite sure that the running code isn't interesting before
> we suppress the backtrace information.
>
> See the thread around here:
>
> https://lkml.kernel.org/r/20160307204317.GR6344 at twins.programming.kicks-ass.net
Makes sense. Thanks for the poitner.
Best Regards,
Petr
next prev parent reply other threads:[~2016-08-16 8:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 16:03 [PATCH v7 0/4] improvements to the nmi_backtrace code Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-08 16:03 ` [PATCH v7 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-09 12:35 ` Petr Mladek
2016-08-09 12:35 ` Petr Mladek
2016-08-08 16:03 ` [PATCH v7 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-09 12:37 ` Petr Mladek
2016-08-09 12:37 ` Petr Mladek
2016-08-08 16:03 ` [PATCH v7 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf
2016-08-08 16:03 ` [PATCH v7 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf
2016-08-08 16:03 ` Chris Metcalf
2016-08-08 16:48 ` Mark Rutland
2016-08-08 16:48 ` Mark Rutland
2016-08-08 16:48 ` Mark Rutland
2016-08-08 16:48 ` Mark Rutland
2016-08-09 10:37 ` Lorenzo Pieralisi
2016-08-09 10:37 ` Lorenzo Pieralisi
2016-08-09 13:25 ` Chris Metcalf
2016-08-09 13:25 ` Chris Metcalf
2016-08-09 13:25 ` Chris Metcalf
2016-08-09 13:25 ` Chris Metcalf
2016-08-09 12:43 ` Petr Mladek
2016-08-09 12:43 ` Petr Mladek
2016-08-09 16:43 ` Chris Metcalf
2016-08-09 16:43 ` Chris Metcalf
2016-08-09 16:43 ` Chris Metcalf
2016-08-09 16:43 ` Chris Metcalf
2016-08-11 15:25 ` Petr Mladek
2016-08-11 15:25 ` Petr Mladek
2016-08-11 15:36 ` Peter Zijlstra
2016-08-11 15:36 ` Peter Zijlstra
2016-08-11 15:36 ` Peter Zijlstra
2016-08-15 16:41 ` Chris Metcalf
2016-08-15 16:41 ` Chris Metcalf
2016-08-15 16:41 ` Chris Metcalf
2016-08-15 16:41 ` Chris Metcalf
2016-08-16 8:04 ` Petr Mladek [this message]
2016-08-16 8:04 ` Petr Mladek
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=20160816080401.GJ13300@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@osdl.org \
--cc=atomlin@redhat.com \
--cc=cmetcalf@mellanox.com \
--cc=daniel.thompson@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.