From: Chris Metcalf <cmetcalf@mellanox.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-arch@vger.kernel.org,
Daniel Thompson <daniel.thompson@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>, Aaron Tomlin <atomlin@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Mon, 21 Mar 2016 13:12:39 -0400 [thread overview]
Message-ID: <56F02B87.2000307@mellanox.com> (raw)
In-Reply-To: <20160321163215.GC6344@twins.programming.kicks-ass.net>
On 03/21/2016 12:32 PM, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 12:15:12PM -0400, Chris Metcalf wrote:
>> On 03/21/2016 11:42 AM, Peter Zijlstra wrote:
>>> The most common idle function for x86 is: mwait_idle_with_hints(),
>>> trouble is, its an inline, so I'm not sure adding __cpuidle to it does
>>> anything.
>> No, you're right, it wouldn't help. I didn't look at the drivers/cpuidle
>> subsystem at all in my patch, since I'm not that familiar with it,
>> but it seems like tagging acpi_processor_ffh_cstate_enter(), as the
>> only user of mwait_idle_with_hints(), will do the job.
> intel_idle() also uses it.
Ah, of course. I was only looking at the config options enabled in the
kernel I was building. I've added INTEL_IDLE now and grep'ed the whole
kernel tree as well, finding a couple of extra possibilities:
I do see mwait used in the ACPI 4.0 Processor Aggregator Device driver, but
this seems sufficiently far removed from regular cpuidle that I don't
think it's appropriate to tag the power_saving_thread() function -
the initial commit talks about using the mechanism "to ride-out
transient electrical and thermal emergencies."
There's also the thermal "powerclamp" driver that enforces a particular
amount of idle time across the system. For this one it's less clear to
me whether this is a valid "idle" state that we should ignore when doing
NMI backtracing. This would be the clamp_thread() function in
drivers/thermal/intel_powerclamp.c. For now I'm not including it,
but what do you think?
> # nm -n ivb-ep-build/vmlinux | awk '/__cpuidle_text_start/ {p=1} {if (p) print $0} /__cpuidle_text_end/ {p=0}'
> ffffffff81b16ca8 T __cpuidle_text_start
> ffffffff81b16cb0 T default_idle
> ffffffff81b16e50 t mwait_idle
> ffffffff81b17080 t cpu_idle_poll
> ffffffff81b17280 T default_idle_call
> ffffffff81b172be T __cpuidle_text_end
>
> So no intel_idle for me..
With the changes discussed so far in this email thread, we've gotten to:
ffffffff818df178 T __cpuidle_text_start
ffffffff818df180 T default_idle
ffffffff818df260 t mwait_idle
ffffffff818df3f0 T acpi_processor_ffh_cstate_enter
ffffffff818df4a0 T default_idle_call
ffffffff818df4e0 t cpu_idle_poll
ffffffff818df600 t intel_idle_freeze
ffffffff818df6a0 t intel_idle
ffffffff818df7b5 T __cpuidle_text_end
This is about 1,600 bytes (or about 450 instructions) that will cause
NMI to skip doing a backtrace if the PC is anywhere in the range.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
WARNING: multiple messages have this Message-ID (diff)
From: Chris Metcalf <cmetcalf@mellanox.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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 v2 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Mon, 21 Mar 2016 13:12:39 -0400 [thread overview]
Message-ID: <56F02B87.2000307@mellanox.com> (raw)
Message-ID: <20160321171239.bWAYyKxghD4TdTpgRB00xAq8Yfp7F5oTCrfBjHZgu4E@z> (raw)
In-Reply-To: <20160321163215.GC6344@twins.programming.kicks-ass.net>
On 03/21/2016 12:32 PM, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 12:15:12PM -0400, Chris Metcalf wrote:
>> On 03/21/2016 11:42 AM, Peter Zijlstra wrote:
>>> The most common idle function for x86 is: mwait_idle_with_hints(),
>>> trouble is, its an inline, so I'm not sure adding __cpuidle to it does
>>> anything.
>> No, you're right, it wouldn't help. I didn't look at the drivers/cpuidle
>> subsystem at all in my patch, since I'm not that familiar with it,
>> but it seems like tagging acpi_processor_ffh_cstate_enter(), as the
>> only user of mwait_idle_with_hints(), will do the job.
> intel_idle() also uses it.
Ah, of course. I was only looking at the config options enabled in the
kernel I was building. I've added INTEL_IDLE now and grep'ed the whole
kernel tree as well, finding a couple of extra possibilities:
I do see mwait used in the ACPI 4.0 Processor Aggregator Device driver, but
this seems sufficiently far removed from regular cpuidle that I don't
think it's appropriate to tag the power_saving_thread() function -
the initial commit talks about using the mechanism "to ride-out
transient electrical and thermal emergencies."
There's also the thermal "powerclamp" driver that enforces a particular
amount of idle time across the system. For this one it's less clear to
me whether this is a valid "idle" state that we should ignore when doing
NMI backtracing. This would be the clamp_thread() function in
drivers/thermal/intel_powerclamp.c. For now I'm not including it,
but what do you think?
> # nm -n ivb-ep-build/vmlinux | awk '/__cpuidle_text_start/ {p=1} {if (p) print $0} /__cpuidle_text_end/ {p=0}'
> ffffffff81b16ca8 T __cpuidle_text_start
> ffffffff81b16cb0 T default_idle
> ffffffff81b16e50 t mwait_idle
> ffffffff81b17080 t cpu_idle_poll
> ffffffff81b17280 T default_idle_call
> ffffffff81b172be T __cpuidle_text_end
>
> So no intel_idle for me..
With the changes discussed so far in this email thread, we've gotten to:
ffffffff818df178 T __cpuidle_text_start
ffffffff818df180 T default_idle
ffffffff818df260 t mwait_idle
ffffffff818df3f0 T acpi_processor_ffh_cstate_enter
ffffffff818df4a0 T default_idle_call
ffffffff818df4e0 t cpu_idle_poll
ffffffff818df600 t intel_idle_freeze
ffffffff818df6a0 t intel_idle
ffffffff818df7b5 T __cpuidle_text_end
This is about 1,600 bytes (or about 450 instructions) that will cause
NMI to skip doing a backtrace if the PC is anywhere in the range.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
WARNING: multiple messages have this Message-ID (diff)
From: cmetcalf@mellanox.com (Chris Metcalf)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Mon, 21 Mar 2016 13:12:39 -0400 [thread overview]
Message-ID: <56F02B87.2000307@mellanox.com> (raw)
In-Reply-To: <20160321163215.GC6344@twins.programming.kicks-ass.net>
On 03/21/2016 12:32 PM, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 12:15:12PM -0400, Chris Metcalf wrote:
>> On 03/21/2016 11:42 AM, Peter Zijlstra wrote:
>>> The most common idle function for x86 is: mwait_idle_with_hints(),
>>> trouble is, its an inline, so I'm not sure adding __cpuidle to it does
>>> anything.
>> No, you're right, it wouldn't help. I didn't look at the drivers/cpuidle
>> subsystem at all in my patch, since I'm not that familiar with it,
>> but it seems like tagging acpi_processor_ffh_cstate_enter(), as the
>> only user of mwait_idle_with_hints(), will do the job.
> intel_idle() also uses it.
Ah, of course. I was only looking at the config options enabled in the
kernel I was building. I've added INTEL_IDLE now and grep'ed the whole
kernel tree as well, finding a couple of extra possibilities:
I do see mwait used in the ACPI 4.0 Processor Aggregator Device driver, but
this seems sufficiently far removed from regular cpuidle that I don't
think it's appropriate to tag the power_saving_thread() function -
the initial commit talks about using the mechanism "to ride-out
transient electrical and thermal emergencies."
There's also the thermal "powerclamp" driver that enforces a particular
amount of idle time across the system. For this one it's less clear to
me whether this is a valid "idle" state that we should ignore when doing
NMI backtracing. This would be the clamp_thread() function in
drivers/thermal/intel_powerclamp.c. For now I'm not including it,
but what do you think?
> # nm -n ivb-ep-build/vmlinux | awk '/__cpuidle_text_start/ {p=1} {if (p) print $0} /__cpuidle_text_end/ {p=0}'
> ffffffff81b16ca8 T __cpuidle_text_start
> ffffffff81b16cb0 T default_idle
> ffffffff81b16e50 t mwait_idle
> ffffffff81b17080 t cpu_idle_poll
> ffffffff81b17280 T default_idle_call
> ffffffff81b172be T __cpuidle_text_end
>
> So no intel_idle for me..
With the changes discussed so far in this email thread, we've gotten to:
ffffffff818df178 T __cpuidle_text_start
ffffffff818df180 T default_idle
ffffffff818df260 t mwait_idle
ffffffff818df3f0 T acpi_processor_ffh_cstate_enter
ffffffff818df4a0 T default_idle_call
ffffffff818df4e0 t cpu_idle_poll
ffffffff818df600 t intel_idle_freeze
ffffffff818df6a0 t intel_idle
ffffffff818df7b5 T __cpuidle_text_end
This is about 1,600 bytes (or about 450 instructions) that will cause
NMI to skip doing a backtrace if the PC is anywhere in the range.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
WARNING: multiple messages have this Message-ID (diff)
From: Chris Metcalf <cmetcalf@mellanox.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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 v2 4/4] nmi_backtrace: generate one-line reports for idle cpus
Date: Mon, 21 Mar 2016 13:12:39 -0400 [thread overview]
Message-ID: <56F02B87.2000307@mellanox.com> (raw)
In-Reply-To: <20160321163215.GC6344@twins.programming.kicks-ass.net>
On 03/21/2016 12:32 PM, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 12:15:12PM -0400, Chris Metcalf wrote:
>> On 03/21/2016 11:42 AM, Peter Zijlstra wrote:
>>> The most common idle function for x86 is: mwait_idle_with_hints(),
>>> trouble is, its an inline, so I'm not sure adding __cpuidle to it does
>>> anything.
>> No, you're right, it wouldn't help. I didn't look at the drivers/cpuidle
>> subsystem at all in my patch, since I'm not that familiar with it,
>> but it seems like tagging acpi_processor_ffh_cstate_enter(), as the
>> only user of mwait_idle_with_hints(), will do the job.
> intel_idle() also uses it.
Ah, of course. I was only looking at the config options enabled in the
kernel I was building. I've added INTEL_IDLE now and grep'ed the whole
kernel tree as well, finding a couple of extra possibilities:
I do see mwait used in the ACPI 4.0 Processor Aggregator Device driver, but
this seems sufficiently far removed from regular cpuidle that I don't
think it's appropriate to tag the power_saving_thread() function -
the initial commit talks about using the mechanism "to ride-out
transient electrical and thermal emergencies."
There's also the thermal "powerclamp" driver that enforces a particular
amount of idle time across the system. For this one it's less clear to
me whether this is a valid "idle" state that we should ignore when doing
NMI backtracing. This would be the clamp_thread() function in
drivers/thermal/intel_powerclamp.c. For now I'm not including it,
but what do you think?
> # nm -n ivb-ep-build/vmlinux | awk '/__cpuidle_text_start/ {p=1} {if (p) print $0} /__cpuidle_text_end/ {p=0}'
> ffffffff81b16ca8 T __cpuidle_text_start
> ffffffff81b16cb0 T default_idle
> ffffffff81b16e50 t mwait_idle
> ffffffff81b17080 t cpu_idle_poll
> ffffffff81b17280 T default_idle_call
> ffffffff81b172be T __cpuidle_text_end
>
> So no intel_idle for me..
With the changes discussed so far in this email thread, we've gotten to:
ffffffff818df178 T __cpuidle_text_start
ffffffff818df180 T default_idle
ffffffff818df260 t mwait_idle
ffffffff818df3f0 T acpi_processor_ffh_cstate_enter
ffffffff818df4a0 T default_idle_call
ffffffff818df4e0 t cpu_idle_poll
ffffffff818df600 t intel_idle_freeze
ffffffff818df6a0 t intel_idle
ffffffff818df7b5 T __cpuidle_text_end
This is about 1,600 bytes (or about 450 instructions) that will cause
NMI to skip doing a backtrace if the PC is anywhere in the range.
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
next prev parent reply other threads:[~2016-03-21 17:12 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 21:40 [PATCH 0/4] improvements to the nmi_backtrace code Chris Metcalf
2016-02-29 21:40 ` Chris Metcalf
2016-02-29 21:40 ` [PATCH 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf
2016-02-29 21:40 ` Chris Metcalf
2016-02-29 21:40 ` [PATCH 2/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf
2016-03-01 14:23 ` Daniel Thompson
2016-03-01 16:01 ` Chris Metcalf
2016-03-07 8:26 ` Daniel Thompson
2016-03-07 17:05 ` Chris Metcalf
2016-03-07 9:48 ` Peter Zijlstra
2016-03-07 17:38 ` Chris Metcalf
2016-03-07 20:43 ` Peter Zijlstra
2016-03-16 17:02 ` [PATCH v2 0/4] improvements to the nmi_backtrace code Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 17:02 ` [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-17 19:36 ` Peter Zijlstra
2016-03-17 19:36 ` Peter Zijlstra
2016-03-17 22:31 ` Chris Metcalf
2016-03-17 22:31 ` Chris Metcalf
2016-03-17 22:38 ` Peter Zijlstra
2016-03-17 22:38 ` Peter Zijlstra
2016-03-17 22:41 ` Chris Metcalf
2016-03-17 22:41 ` Chris Metcalf
2016-03-17 23:14 ` Peter Zijlstra
2016-03-17 23:14 ` Peter Zijlstra
2016-03-17 22:55 ` Paul E. McKenney
2016-03-17 22:55 ` Paul E. McKenney
2016-03-17 23:09 ` Peter Zijlstra
2016-03-17 23:09 ` Peter Zijlstra
2016-03-17 23:11 ` Peter Zijlstra
2016-03-17 23:11 ` Peter Zijlstra
2016-03-18 0:28 ` Paul E. McKenney
2016-03-18 0:28 ` Paul E. McKenney
2016-03-18 0:17 ` Chris Metcalf
2016-03-18 0:17 ` Chris Metcalf
2016-03-18 0:33 ` Paul E. McKenney
2016-03-18 0:33 ` Paul E. McKenney
2016-03-18 9:40 ` Daniel Thompson
2016-03-18 9:40 ` Daniel Thompson
2016-03-18 23:54 ` Paul E. McKenney
2016-03-18 23:54 ` Paul E. McKenney
2016-03-16 17:02 ` [PATCH v2 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 17:02 ` [PATCH v2 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf
2016-03-16 17:02 ` [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 17:02 ` Chris Metcalf
2016-03-16 18:46 ` kbuild test robot
2016-03-16 18:46 ` kbuild test robot
2016-03-16 18:46 ` kbuild test robot
2016-03-16 18:46 ` kbuild test robot
2016-03-21 15:38 ` Peter Zijlstra
2016-03-21 15:38 ` Peter Zijlstra
2016-03-21 15:38 ` Peter Zijlstra
2016-03-21 15:46 ` Chris Metcalf
2016-03-21 15:46 ` Chris Metcalf
2016-03-21 15:46 ` Chris Metcalf
2016-03-21 15:46 ` Chris Metcalf
2016-03-21 15:42 ` Peter Zijlstra
2016-03-21 15:42 ` Peter Zijlstra
2016-03-21 16:15 ` Chris Metcalf
2016-03-21 16:15 ` Chris Metcalf
2016-03-21 16:15 ` Chris Metcalf
2016-03-21 16:32 ` Peter Zijlstra
2016-03-21 16:32 ` Peter Zijlstra
2016-03-21 17:12 ` Chris Metcalf [this message]
2016-03-21 17:12 ` Chris Metcalf
2016-03-21 17:12 ` Chris Metcalf
2016-03-21 17:12 ` Chris Metcalf
2016-03-21 17:17 ` Peter Zijlstra
2016-03-21 17:17 ` Peter Zijlstra
2016-03-21 16:48 ` Peter Zijlstra
2016-03-21 16:48 ` Peter Zijlstra
2016-03-21 21:49 ` Peter Zijlstra
2016-03-21 21:49 ` Peter Zijlstra
2016-03-22 17:19 ` [PATCH v3 0/4] improvements to the nmi_backtrace code Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` [PATCH v3 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` [PATCH v3 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` [PATCH v3 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf
2016-03-22 17:19 ` [PATCH v3 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:19 ` Chris Metcalf
2016-03-22 17:30 ` Peter Zijlstra
2016-03-22 17:30 ` Peter Zijlstra
2016-03-22 22:28 ` Rafael J. Wysocki
2016-03-22 22:28 ` Rafael J. Wysocki
2016-03-22 22:31 ` Rafael J. Wysocki
2016-03-22 22:31 ` Rafael J. Wysocki
2016-03-22 22:45 ` Peter Zijlstra
2016-03-22 22:45 ` Peter Zijlstra
2016-03-23 0:50 ` Rafael J. Wysocki
2016-03-23 0:50 ` Rafael J. Wysocki
2016-03-23 7:53 ` Peter Zijlstra
2016-03-23 7:53 ` Peter Zijlstra
2016-03-30 17:16 ` [PATCH v4 0/4] improvements to the nmi_backtrace code Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` [PATCH v4 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` [PATCH v4 2/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` [PATCH v4 3/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf
2016-03-30 17:16 ` [PATCH v4 4/4] nmi_backtrace: generate one-line reports for idle cpus Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-03-30 17:16 ` Chris Metcalf
2016-02-29 21:40 ` [PATCH 3/4] nmi_backtrace: do a local dump_stack() instead of a self-NMI Chris Metcalf
2016-02-29 21:40 ` Chris Metcalf
2016-02-29 21:40 ` [PATCH 4/4] arch/tile: adopt the new nmi_backtrace framework Chris Metcalf
2016-03-01 0:49 ` [PATCH 0/4] improvements to the nmi_backtrace code Andrew Morton
2016-03-01 0:49 ` Andrew Morton
2016-03-01 10:01 ` Petr Mladek
2016-03-01 10:01 ` 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=56F02B87.2000307@mellanox.com \
--to=cmetcalf@mellanox.com \
--cc=akpm@osdl.org \
--cc=atomlin@redhat.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=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.