Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1361950 > unrolled thread

Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle  cpus Peter Zijlstra <peterz@infradead.org> - 2016-03-21 16:50 +0100
    Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle  cpus Peter Zijlstra <peterz@infradead.org> - 2016-03-21 17:40 +0100
      Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle  cpus Peter Zijlstra <peterz@infradead.org> - 2016-03-21 18:20 +0100

#1361950 — Re: [PATCH v2 4/4] nmi_backtrace: generate one-line reports for idle cpus

On Wed, Mar 16, 2016 at 01:02:13PM -0400, Chris Metcalf wrote:
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 9f7c21c22477..d569ae7fde37 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -298,7 +298,7 @@ void arch_cpu_idle(void)
>  /*
>   * We use this if we don't have any better idle routine..
>   */
> -void default_idle(void)
> +void __cpuidle default_idle(void)
>  {
>  	trace_cpu_idle_rcuidle(1, smp_processor_id());
>  	safe_halt();
> @@ -413,7 +413,7 @@ static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
>   * with interrupts enabled and no flags, which is backwards compatible with the
>   * original MWAIT implementation.
>   */
> -static void mwait_idle(void)
> +static __cpuidle void mwait_idle(void)
>  {
>  	if (!current_set_polling_and_test()) {
>  		trace_cpu_idle_rcuidle(1, smp_processor_id());

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.

I've yet to find the magic objdump incantation to check. Or rather
objdump -h doesn't appear to list .cpuidle.text at all :/

I'm probably doing something silly...

[toc] | [next] | [standalone]

#1361982

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.

> >I've yet to find the magic objdump incantation to check. Or rather
> >objdump -h doesn't appear to list .cpuidle.text at all :/
> >
> >I'm probably doing something silly...
> 
> The easiest way to check for a given function is just to look
> at the "nm -n" output and see that all the functions you expect
> to reflect idle behavior are in the cpuidle begin/end range.

# 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..

> objdump -h certainly works to show .cpuidle.text if you look at
> individual objects (e.g. arch/x86/kernel/process.o) but by the time
> you're looking at the linked vmlinux image they have all been linked
> into the giant .text section.

Indeed.

[toc] | [prev] | [next] | [standalone]

#1362018

On Mon, Mar 21, 2016 at 01:12:39PM -0400, Chris Metcalf wrote:
> 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?

Both the acpi power aggregator and the powerclamp driver are forced idle
and have some serious issues, so are safe to ignore for now.

Also, I would explicitly not include them, because forced idle might
still be interesting.


> ># 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

You can skip this one, that only happens when you suspend to idle.

> 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.

Yeah, the alternative is making mwait_idle_with_hints an actual
function, but then we get to somehow exclude the other users like the
forced idle stuff.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web