From: "Ronny Tschüter" <Ronny.Tschueter@tu-dresden.de>
To: "Robert Schöne" <robert.schoene@tu-dresden.de>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
rostedt@goodmis.org, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Tracing of power:power_start events doesn't work
Date: Fri, 11 Jun 2010 12:26:47 +0200 [thread overview]
Message-ID: <4C120F67.3050400@tu-dresden.de> (raw)
In-Reply-To: <1273654646.3598.227.camel@localhost>
On 12/05/2010 10:57, Robert Schöne wrote:
> On Wed, den 05.05.2010-05-05, 07:33 -0700 schrieb Arjan van de Ven:
>
>> On 5/5/2010 7:31, Steven Rostedt wrote:
>>
>>> On Wed, 2010-05-05 at 16:11 +0200, Ronny Tsch�ter wrote:
>>>
>>>
>>>> /*
>>>> * Include the apic definitions for x86 to have the APIC timer related
>>>> defines
>>>> @@ -796,6 +797,18 @@ static int acpi_idle_bm_check(void)
>>>> */
>>>> static inline void acpi_idle_do_entry(struct acpi_processor_cx *cx)
>>>> {
>>>> + switch (cx->type) {
>>>> + case ACPI_STATE_C1:
>>>> + trace_power_start(POWER_CSTATE, 1);
>>>> + break;
>>>> + case ACPI_STATE_C2:
>>>> + trace_power_start(POWER_CSTATE, 2);
>>>> + break;
>>>> + case ACPI_STATE_C3:
>>>> + trace_power_start(POWER_CSTATE, 3);
>>>> + break;
>>>> + }
>>>> +
>>>>
>>> Depending on gcc, the above can bloat the code since each call to
>>> trace_power_start() is a macro expanded. Try to call it just once.
>>> Perhaps one of the following:
>>>
>> the code is also incorrect fundamentally.
>> You need to pass in the mwait value or equivalent; the ACPI STATE type is
>> pretty much useless random garbage and should completely be ignored.
>>
> You're correct for your case (switching to c-state via monitor/mwait).
> But the current implementation is broken too. It works only if your
> kernel uses processor_idle AND monitor/mwait. For all other cases it
> fails - may it be on Ronnys system, that uses IO port based C-states or
> my system, that uses cpu_idle (not processor_idle).
>
> I'd suggest, that it should work for IO port based switches and could be
> included in the syntactic block of that case.
> Afaik, halt means that the processor goes to C1. So in this block, there
> could be a power_start event too with 1 as new state. (Maybe there are
> problems with AMDs C1E which would be reported as C1.)
>
> Robert
>
Unfortunately the bug still exists in kernel 2.6.34. On my system I'm
not able to trace power:power_start events, because they are not
reported. Regarding to the preceding comments I moved my code snippet
into the IO port based C-state part of acpi_idle_do_entry(). Therefore
it should not interfere with the other two C-state calls in this function.
Furthermore a lot of other code sequences in processor_idle.c use the
ACPI STATE type in if- or switch-statements. So I don't think that ACPI
STATE type is useless garbage.
Finally here is my new patch:
diff --git a/old/processor_idle.c b/new/processor_idle.c
index 5939e7f..5818522 100644
--- a/old/processor_idle.c
+++ b/new/processor_idle.c
@@ -43,6 +43,7 @@
#include <linux/clockchips.h>
#include <linux/cpuidle.h>
#include <linux/irqflags.h>
+#include <trace/events/power.h>
/*
* Include the apic definitions for x86 to have the APIC timer related
defines
@@ -807,6 +808,10 @@ static inline void acpi_idle_do_entry(struct
acpi_processor_cx *cx)
} else {
int unused;
/* IO port based C-state */
+ trace_power_start(POWER_CSTATE,
+ cx->type == ACPI_STATE_C1 ? 1 :
+ cx->type == ACPI_STATE_C2 ? 2 :
+ 3);
inb(cx->address);
/* Dummy wait op - must do something useless after P_LVL2 read
because chipsets cannot guarantee that STPCLK# signal
next prev parent reply other threads:[~2010-06-11 10:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 13:19 Tracing of power:power_start events doesn't work Ronny Tschüter
2010-05-03 21:36 ` Frank Ch. Eigler
2010-05-05 0:31 ` Steven Rostedt
2010-05-05 6:34 ` Ronny Tschüter
2010-05-05 17:23 ` Frederic Weisbecker
2010-05-06 6:32 ` Ronny Tschüter
2010-05-05 14:11 ` Ronny Tschüter
2010-05-05 14:31 ` Steven Rostedt
2010-05-05 14:33 ` Arjan van de Ven
2010-05-12 8:57 ` Robert Schöne
2010-06-11 10:26 ` Ronny Tschüter [this message]
2010-06-29 14:49 ` Ronny Tschüter
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=4C120F67.3050400@tu-dresden.de \
--to=ronny.tschueter@tu-dresden.de \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=robert.schoene@tu-dresden.de \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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.