All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
@ 2011-08-19 15:04 tom.leiming
  2011-08-19 15:04 ` [PATCH 2/3] trace points: power: remove 'cpu_id' from trace_power_domain_target tom.leiming
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: tom.leiming @ 2011-08-19 15:04 UTC (permalink / raw)
  To: rostedt, fweisbec, jean.pihet, mingo, trenn
  Cc: linux-kernel, linux-omap, Ming Lei

From: Ming Lei <tom.leiming@gmail.com>

This patch removes the 'cpu_id' parameter of the clock_*
trace point, based on the ideas below:

- the cpu_id which is passed to trace point is always the current
  cpu
- the current cpu info has been included into the trace result already
- smp_processor_id() can't be used safely in preemptible context.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
 Documentation/trace/events-power.txt |    6 +++---
 arch/arm/mach-omap2/clock.c          |    6 +++---
 include/trace/events/power.h         |   22 ++++++++++------------
 3 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index 96d87b6..3726ba5 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -71,9 +71,9 @@ power_start event.
 The clock events are used for clock enable/disable and for
 clock rate change.
 
-clock_enable		"%s state=%lu cpu_id=%lu"
-clock_disable		"%s state=%lu cpu_id=%lu"
-clock_set_rate		"%s state=%lu cpu_id=%lu"
+clock_enable		"%s state=%lu"
+clock_disable		"%s state=%lu"
+clock_set_rate		"%s state=%lu"
 
 The first parameter gives the clock name (e.g. "gpio1_iclk").
 The second parameter is '1' for enable, '0' for disable, the target
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 1f3481f..05111b1 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -285,7 +285,7 @@ void omap2_clk_disable(struct clk *clk)
 	pr_debug("clock: %s: disabling in hardware\n", clk->name);
 
 	if (clk->ops && clk->ops->disable) {
-		trace_clock_disable(clk->name, 0, smp_processor_id());
+		trace_clock_disable(clk->name, 0);
 		clk->ops->disable(clk);
 	}
 
@@ -339,7 +339,7 @@ int omap2_clk_enable(struct clk *clk)
 	}
 
 	if (clk->ops && clk->ops->enable) {
-		trace_clock_enable(clk->name, 1, smp_processor_id());
+		trace_clock_enable(clk->name, 1);
 		ret = clk->ops->enable(clk);
 		if (ret) {
 			WARN(1, "clock: %s: could not enable: %d\n",
@@ -380,7 +380,7 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
 
 	/* dpll_ck, core_ck, virt_prcm_set; plus all clksel clocks */
 	if (clk->set_rate) {
-		trace_clock_set_rate(clk->name, rate, smp_processor_id());
+		trace_clock_set_rate(clk->name, rate);
 		ret = clk->set_rate(clk, rate);
 	}
 
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 1bcc2a8..e315e68 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -162,45 +162,43 @@ static inline void trace_power_frequency(u64 type, u64 state, u64 cpuid) {};
  */
 DECLARE_EVENT_CLASS(clock,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id),
+	TP_ARGS(name, state),
 
 	TP_STRUCT__entry(
 		__string(       name,           name            )
 		__field(        u64,            state           )
-		__field(        u64,            cpu_id          )
 	),
 
 	TP_fast_assign(
 		__assign_str(name, name);
 		__entry->state = state;
-		__entry->cpu_id = cpu_id;
 	),
 
-	TP_printk("%s state=%lu cpu_id=%lu", __get_str(name),
-		(unsigned long)__entry->state, (unsigned long)__entry->cpu_id)
+	TP_printk("%s state=%lu", __get_str(name),
+		(unsigned long)__entry->state)
 );
 
 DEFINE_EVENT(clock, clock_enable,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id)
+	TP_ARGS(name, state)
 );
 
 DEFINE_EVENT(clock, clock_disable,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id)
+	TP_ARGS(name, state)
 );
 
 DEFINE_EVENT(clock, clock_set_rate,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id)
+	TP_ARGS(name, state)
 );
 
 /*
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 2/3] trace points: power: remove 'cpu_id' from trace_power_domain_target
  2011-08-19 15:04 [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* tom.leiming
@ 2011-08-19 15:04 ` tom.leiming
  2011-08-19 15:04 ` [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle tom.leiming
  2011-08-19 15:14 ` [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* Steven Rostedt
  2 siblings, 0 replies; 15+ messages in thread
From: tom.leiming @ 2011-08-19 15:04 UTC (permalink / raw)
  To: rostedt, fweisbec, jean.pihet, mingo, trenn
  Cc: linux-kernel, linux-omap, Ming Lei

From: Ming Lei <tom.leiming@gmail.com>

This patch removes the 'cpu_id' parameter of the power_domain_target
trace point, based on the ideas below:

- the cpu_id which is passed to trace point is always the current
  cpu
- the current cpu info has been included into the trace result
  already
- smp_processor_id() can't be used safely in preemptible context.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
 Documentation/trace/events-power.txt |    2 +-
 arch/arm/mach-omap2/powerdomain.c    |    6 ++----
 include/trace/events/power.h         |   14 ++++++--------
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index 3726ba5..e9d5fe3 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -83,7 +83,7 @@ clock rate for set_rate.
 =======================
 The power domain events are used for power domains transitions
 
-power_domain_target	"%s state=%lu cpu_id=%lu"
+power_domain_target	"%s state=%lu"
 
 The first parameter gives the power domain name (e.g. "mpu_pwrdm").
 The second parameter is the power domain target state.
diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..00e017e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -160,8 +160,7 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
 			trace_state = (PWRDM_TRACE_STATES_FLAG |
 				       ((state & OMAP_POWERSTATE_MASK) << 8) |
 				       ((prev & OMAP_POWERSTATE_MASK) << 0));
-			trace_power_domain_target(pwrdm->name, trace_state,
-						  smp_processor_id());
+			trace_power_domain_target(pwrdm->name, trace_state);
 		}
 		break;
 	default:
@@ -423,8 +422,7 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
 
 	if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
 		/* Trace the pwrdm desired target state */
-		trace_power_domain_target(pwrdm->name, pwrst,
-					  smp_processor_id());
+		trace_power_domain_target(pwrdm->name, pwrst);
 		/* Program the pwrdm desired target state */
 		ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
 	}
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index e315e68..3878edc 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -206,31 +206,29 @@ DEFINE_EVENT(clock, clock_set_rate,
  */
 DECLARE_EVENT_CLASS(power_domain,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id),
+	TP_ARGS(name, state),
 
 	TP_STRUCT__entry(
 		__string(       name,           name            )
 		__field(        u64,            state           )
-		__field(        u64,            cpu_id          )
 	),
 
 	TP_fast_assign(
 		__assign_str(name, name);
 		__entry->state = state;
-		__entry->cpu_id = cpu_id;
 ),
 
-	TP_printk("%s state=%lu cpu_id=%lu", __get_str(name),
-		(unsigned long)__entry->state, (unsigned long)__entry->cpu_id)
+	TP_printk("%s state=%lu", __get_str(name),
+		(unsigned long)__entry->state)
 );
 
 DEFINE_EVENT(power_domain, power_domain_target,
 
-	TP_PROTO(const char *name, unsigned int state, unsigned int cpu_id),
+	TP_PROTO(const char *name, unsigned int state),
 
-	TP_ARGS(name, state, cpu_id)
+	TP_ARGS(name, state)
 );
 #endif /* _TRACE_POWER_H */
 
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-08-19 15:04 [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* tom.leiming
  2011-08-19 15:04 ` [PATCH 2/3] trace points: power: remove 'cpu_id' from trace_power_domain_target tom.leiming
@ 2011-08-19 15:04 ` tom.leiming
  2011-08-19 20:31   ` Thomas Renninger
  2011-08-19 15:14 ` [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* Steven Rostedt
  2 siblings, 1 reply; 15+ messages in thread
From: tom.leiming @ 2011-08-19 15:04 UTC (permalink / raw)
  To: rostedt, fweisbec, jean.pihet, mingo, trenn
  Cc: linux-kernel, linux-omap, Ming Lei

From: Ming Lei <tom.leiming@gmail.com>

This patch removes the 'cpu_id' parameter of the cpu_idle
trace point, based on the ideas below:

- the cpu_id which is passed to trace point is always the current
  cpu
- the current cpu info has been included into the trace result
  already
- smp_processor_id() can't be used safely in preemptible context.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
 Documentation/trace/events-power.txt |    6 +++---
 arch/arm/mach-omap2/pm34xx.c         |    4 ++--
 arch/x86/kernel/process.c            |   12 ++++++------
 drivers/cpuidle/cpuidle.c            |    4 ++--
 include/trace/events/power.h         |   15 ++++++++++++---
 5 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index e9d5fe3..9f2f96c 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -23,7 +23,7 @@ Cf. include/trace/events/power.h for the events definitions.
 A 'cpu' event class gathers the CPU-related events: cpuidle and
 cpufreq.
 
-cpu_idle		"state=%lu cpu_id=%lu"
+cpu_idle		"state=%lu"
 cpu_frequency		"state=%lu cpu_id=%lu"
 
 A suspend event is used to indicate the system going in and out of the
@@ -33,8 +33,8 @@ machine_suspend		"state=%lu"
 
 
 Note: the value of '-1' or '4294967295' for state means an exit from the current state,
-i.e. trace_cpu_idle(4, smp_processor_id()) means that the system
-enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
+i.e. trace_cpu_idle(4) means that the system
+enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT)
 means that the system exits the previous idle state.
 
 The event which has 'state=4294967295' in the trace is very important to the user
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7255d9b..cde9a11 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -502,12 +502,12 @@ static void omap3_pm_idle(void)
 		goto out;
 
 	trace_power_start(POWER_CSTATE, 1, smp_processor_id());
-	trace_cpu_idle(1, smp_processor_id());
+	trace_cpu_idle(1);
 
 	omap_sram_idle();
 
 	trace_power_end(smp_processor_id());
-	trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+	trace_cpu_idle(PWR_EVENT_EXIT);
 
 out:
 	local_fiq_enable();
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e7e3b01..fb9e92b 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -378,7 +378,7 @@ void default_idle(void)
 {
 	if (hlt_use_halt()) {
 		trace_power_start(POWER_CSTATE, 1, smp_processor_id());
-		trace_cpu_idle(1, smp_processor_id());
+		trace_cpu_idle(1);
 		current_thread_info()->status &= ~TS_POLLING;
 		/*
 		 * TS_POLLING-cleared state must be visible before we
@@ -392,7 +392,7 @@ void default_idle(void)
 			local_irq_enable();
 		current_thread_info()->status |= TS_POLLING;
 		trace_power_end(smp_processor_id());
-		trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+		trace_cpu_idle(PWR_EVENT_EXIT);
 	} else {
 		local_irq_enable();
 		/* loop is done by the caller */
@@ -443,7 +443,7 @@ static void mwait_idle(void)
 {
 	if (!need_resched()) {
 		trace_power_start(POWER_CSTATE, 1, smp_processor_id());
-		trace_cpu_idle(1, smp_processor_id());
+		trace_cpu_idle(1);
 		if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
 			clflush((void *)&current_thread_info()->flags);
 
@@ -454,7 +454,7 @@ static void mwait_idle(void)
 		else
 			local_irq_enable();
 		trace_power_end(smp_processor_id());
-		trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+		trace_cpu_idle(PWR_EVENT_EXIT);
 	} else
 		local_irq_enable();
 }
@@ -467,12 +467,12 @@ static void mwait_idle(void)
 static void poll_idle(void)
 {
 	trace_power_start(POWER_CSTATE, 0, smp_processor_id());
-	trace_cpu_idle(0, smp_processor_id());
+	trace_cpu_idle(0);
 	local_irq_enable();
 	while (!need_resched())
 		cpu_relax();
 	trace_power_end(smp_processor_id());
-	trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+	trace_cpu_idle(PWR_EVENT_EXIT);
 }
 
 /*
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index d4c5423..7980732 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -106,12 +106,12 @@ int cpuidle_idle_call(void)
 	dev->last_state = target_state;
 
 	trace_power_start(POWER_CSTATE, next_state, dev->cpu);
-	trace_cpu_idle(next_state, dev->cpu);
+	trace_cpu_idle(next_state);
 
 	dev->last_residency = target_state->enter(dev, target_state);
 
 	trace_power_end(dev->cpu);
-	trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
+	trace_cpu_idle(PWR_EVENT_EXIT);
 
 	if (dev->last_state)
 		target_state = dev->last_state;
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 3878edc..8a579bd 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -27,11 +27,20 @@ DECLARE_EVENT_CLASS(cpu,
 		  (unsigned long)__entry->cpu_id)
 );
 
-DEFINE_EVENT(cpu, cpu_idle,
+TRACE_EVENT(cpu_idle,
+	TP_PROTO(unsigned int state),
 
-	TP_PROTO(unsigned int state, unsigned int cpu_id),
+	TP_ARGS(state),
+
+	TP_STRUCT__entry(
+		__field(	u32,		state		)
+	),
+
+	TP_fast_assign(
+		__entry->state = state;
+	),
 
-	TP_ARGS(state, cpu_id)
+	TP_printk("state=%lu", (unsigned long)__entry->state)
 );
 
 /* This file can get included multiple times, TRACE_HEADER_MULTI_READ at top */
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
  2011-08-19 15:04 [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* tom.leiming
  2011-08-19 15:04 ` [PATCH 2/3] trace points: power: remove 'cpu_id' from trace_power_domain_target tom.leiming
  2011-08-19 15:04 ` [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle tom.leiming
@ 2011-08-19 15:14 ` Steven Rostedt
  2011-08-19 15:39   ` Ming Lei
  2 siblings, 1 reply; 15+ messages in thread
From: Steven Rostedt @ 2011-08-19 15:14 UTC (permalink / raw)
  To: tom.leiming
  Cc: fweisbec, jean.pihet, mingo, trenn, linux-kernel, linux-omap,
	Arjan van de Ven

On Fri, 2011-08-19 at 23:04 +0800, tom.leiming@gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
> 
> This patch removes the 'cpu_id' parameter of the clock_*
> trace point, based on the ideas below:
> 
> - the cpu_id which is passed to trace point is always the current
>   cpu
> - the current cpu info has been included into the trace result already
> - smp_processor_id() can't be used safely in preemptible context.
> 

Do you know if these changes wont break powertop?

-- Steve



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
  2011-08-19 15:14 ` [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* Steven Rostedt
@ 2011-08-19 15:39   ` Ming Lei
  2011-08-19 16:16     ` Arjan van de Ven
  0 siblings, 1 reply; 15+ messages in thread
From: Ming Lei @ 2011-08-19 15:39 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: fweisbec, jean.pihet, mingo, trenn, linux-kernel, linux-omap,
	Arjan van de Ven

Hi,

On Fri, Aug 19, 2011 at 11:14 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> Do you know if these changes wont break powertop?

I have run powertop 1.13 on these changes, and found it works well
just like before,
no breaks found.

thanks,
-- 
Ming Lei

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
  2011-08-19 15:39   ` Ming Lei
@ 2011-08-19 16:16     ` Arjan van de Ven
  2011-08-20  2:44         ` Ming Lei
  0 siblings, 1 reply; 15+ messages in thread
From: Arjan van de Ven @ 2011-08-19 16:16 UTC (permalink / raw)
  To: Ming Lei
  Cc: Steven Rostedt, fweisbec, jean.pihet, mingo, trenn, linux-kernel,
	linux-omap

On 8/19/2011 8:39 AM, Ming Lei wrote:
> Hi,
>
> On Fri, Aug 19, 2011 at 11:14 PM, Steven Rostedt<rostedt@goodmis.org>  wrote:
>> Do you know if these changes wont break powertop?
> I have run powertop 1.13 on these changes, and found it works well
> just like before,
> no breaks found.
please use powertop 1.98 instead
1.13 does not use trace events while 1.98 does

>
> thanks,


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-08-19 15:04 ` [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle tom.leiming
@ 2011-08-19 20:31   ` Thomas Renninger
  2011-08-20  2:40       ` Ming Lei
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas Renninger @ 2011-08-19 20:31 UTC (permalink / raw)
  To: tom.leiming
  Cc: rostedt, fweisbec, jean.pihet, mingo, linux-kernel, linux-omap,
	Len Brown

On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
> 
> This patch removes the 'cpu_id' parameter of the cpu_idle
> trace point, based on the ideas below:
> 
> - the cpu_id which is passed to trace point is always the current
>   cpu
Are you sure this will always be true?

> - the current cpu info has been included into the trace result
>   already
> - smp_processor_id() can't be used safely in preemptible context.

The cpuid has been added to idle events on purpose for example to be 
able to pass C-state dependencies.
2 cores may only enter a deeper sleep state if the 2nd core enters it
as well.
There may be architectures where you could trigger a sleep state on
a foreign cpu.

This may not be used now, but if the kernel does want to use it, you do
not want to adjust a dozen userspace apps.

Not sure how to quickly solve the:
"smp_processor_id() can't be used safely in preemptible context."
problem, though.
A convention could be declared that if -1 is passed, it's the same cpu
entering the sleep state as the running one. This will probably
break userspace apps as well...

Best would be to clean up x86 and let idle routines always be entered
from cpuidle subsystem which knows the cpu id already and eliminate
all idle functions in arch/x86/kernel/process.c.

   Thomas

PS: I do not care about patch 1 and 2 as these events are ARM specific
afaik. But I vote against this one.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-08-19 20:31   ` Thomas Renninger
@ 2011-08-20  2:40       ` Ming Lei
  0 siblings, 0 replies; 15+ messages in thread
From: Ming Lei @ 2011-08-20  2:40 UTC (permalink / raw)
  To: Thomas Renninger
  Cc: rostedt, fweisbec, jean.pihet, mingo, linux-kernel, linux-omap,
	Len Brown

Hi,

2011/8/20 Thomas Renninger <trenn@suse.de>:
> On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:
>> From: Ming Lei <tom.leiming@gmail.com>
>>
>> This patch removes the 'cpu_id' parameter of the cpu_idle
>> trace point, based on the ideas below:
>>
>> - the cpu_id which is passed to trace point is always the current
>>   cpu
> Are you sure this will always be true?

It is sure at least now,  the only place to pass 'dev->cpu' is inside
cpuidle_idle_call,
but the cpuidle_device is got from __this_cpu_read(cpuidle_devices),
so it should
be true for such case.

>
>> - the current cpu info has been included into the trace result
>>   already
>> - smp_processor_id() can't be used safely in preemptible context.
>
> The cpuid has been added to idle events on purpose for example to be
> able to pass C-state dependencies.
> 2 cores may only enter a deeper sleep state if the 2nd core enters it
> as well.
> There may be architectures where you could trigger a sleep state on
> a foreign cpu.
>
> This may not be used now, but if the kernel does want to use it, you do
> not want to adjust a dozen userspace apps.
>
> Not sure how to quickly solve the:
> "smp_processor_id() can't be used safely in preemptible context."
> problem, though.
> A convention could be declared that if -1 is passed, it's the same cpu
> entering the sleep state as the running one. This will probably
> break userspace apps as well...
>
> Best would be to clean up x86 and let idle routines always be entered
> from cpuidle subsystem which knows the cpu id already and eliminate
> all idle functions in arch/x86/kernel/process.c.
>
>   Thomas
>
> PS: I do not care about patch 1 and 2 as these events are ARM specific
> afaik. But I vote against this one.
>


thanks,
-- 
Ming Lei

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
@ 2011-08-20  2:40       ` Ming Lei
  0 siblings, 0 replies; 15+ messages in thread
From: Ming Lei @ 2011-08-20  2:40 UTC (permalink / raw)
  To: Thomas Renninger
  Cc: rostedt, fweisbec, jean.pihet, mingo, linux-kernel, linux-omap,
	Len Brown

Hi,

2011/8/20 Thomas Renninger <trenn@suse.de>:
> On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:
>> From: Ming Lei <tom.leiming@gmail.com>
>>
>> This patch removes the 'cpu_id' parameter of the cpu_idle
>> trace point, based on the ideas below:
>>
>> - the cpu_id which is passed to trace point is always the current
>>   cpu
> Are you sure this will always be true?

It is sure at least now,  the only place to pass 'dev->cpu' is inside
cpuidle_idle_call,
but the cpuidle_device is got from __this_cpu_read(cpuidle_devices),
so it should
be true for such case.

>
>> - the current cpu info has been included into the trace result
>>   already
>> - smp_processor_id() can't be used safely in preemptible context.
>
> The cpuid has been added to idle events on purpose for example to be
> able to pass C-state dependencies.
> 2 cores may only enter a deeper sleep state if the 2nd core enters it
> as well.
> There may be architectures where you could trigger a sleep state on
> a foreign cpu.
>
> This may not be used now, but if the kernel does want to use it, you do
> not want to adjust a dozen userspace apps.
>
> Not sure how to quickly solve the:
> "smp_processor_id() can't be used safely in preemptible context."
> problem, though.
> A convention could be declared that if -1 is passed, it's the same cpu
> entering the sleep state as the running one. This will probably
> break userspace apps as well...
>
> Best would be to clean up x86 and let idle routines always be entered
> from cpuidle subsystem which knows the cpu id already and eliminate
> all idle functions in arch/x86/kernel/process.c.
>
>   Thomas
>
> PS: I do not care about patch 1 and 2 as these events are ARM specific
> afaik. But I vote against this one.
>


thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
  2011-08-19 16:16     ` Arjan van de Ven
@ 2011-08-20  2:44         ` Ming Lei
  0 siblings, 0 replies; 15+ messages in thread
From: Ming Lei @ 2011-08-20  2:44 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Steven Rostedt, fweisbec, jean.pihet, mingo, trenn, linux-kernel,
	linux-omap

On Sat, Aug 20, 2011 at 12:16 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
> On 8/19/2011 8:39 AM, Ming Lei wrote:
>>
>> Hi,
>>
>> On Fri, Aug 19, 2011 at 11:14 PM, Steven Rostedt<rostedt@goodmis.org>
>>  wrote:
>>>
>>> Do you know if these changes wont break powertop?
>>
>> I have run powertop 1.13 on these changes, and found it works well
>> just like before,
>> no breaks found.
>
> please use powertop 1.98 instead
> 1.13 does not use trace events while 1.98 does

>From the link below:

       http://www.lesswatts.org/projects/powertop/download.php

It mentions that "Version 1.13 is the latest version of PowerTOP", also
no any information about 1.98. so where can I get 1.98?

thanks,
-- 
Ming Lei

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
@ 2011-08-20  2:44         ` Ming Lei
  0 siblings, 0 replies; 15+ messages in thread
From: Ming Lei @ 2011-08-20  2:44 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Steven Rostedt, fweisbec, jean.pihet, mingo, trenn, linux-kernel,
	linux-omap

On Sat, Aug 20, 2011 at 12:16 AM, Arjan van de Ven
<arjan@linux.intel.com> wrote:
> On 8/19/2011 8:39 AM, Ming Lei wrote:
>>
>> Hi,
>>
>> On Fri, Aug 19, 2011 at 11:14 PM, Steven Rostedt<rostedt@goodmis.org>
>>  wrote:
>>>
>>> Do you know if these changes wont break powertop?
>>
>> I have run powertop 1.13 on these changes, and found it works well
>> just like before,
>> no breaks found.
>
> please use powertop 1.98 instead
> 1.13 does not use trace events while 1.98 does

From the link below:

       http://www.lesswatts.org/projects/powertop/download.php

It mentions that "Version 1.13 is the latest version of PowerTOP", also
no any information about 1.98. so where can I get 1.98?

thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_*
  2011-08-20  2:44         ` Ming Lei
  (?)
@ 2011-08-20 15:59         ` Arjan van de Ven
  -1 siblings, 0 replies; 15+ messages in thread
From: Arjan van de Ven @ 2011-08-20 15:59 UTC (permalink / raw)
  To: Ming Lei
  Cc: Steven Rostedt, fweisbec, jean.pihet, mingo, trenn, linux-kernel,
	linux-omap

It mentions that "Version 1.13 is the latest version of PowerTOP", also 
no any information about 1.98. so where can I get 1.98? thanks,

http://www.kernel.org/pub/linux/status/powertop


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-08-20  2:40       ` Ming Lei
  (?)
@ 2011-08-22  8:27       ` Thomas Renninger
  2011-09-02  7:26         ` Jean Pihet
  -1 siblings, 1 reply; 15+ messages in thread
From: Thomas Renninger @ 2011-08-22  8:27 UTC (permalink / raw)
  To: Ming Lei
  Cc: rostedt, fweisbec, jean.pihet, mingo, linux-kernel, linux-omap,
	Len Brown

On Saturday, August 20, 2011 04:40:09 AM Ming Lei wrote:
> Hi,
> 
> 2011/8/20 Thomas Renninger <trenn@suse.de>:
> > On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:
> >> From: Ming Lei <tom.leiming@gmail.com>
> >>
> >> This patch removes the 'cpu_id' parameter of the cpu_idle
> >> trace point, based on the ideas below:
> >>
> >> - the cpu_id which is passed to trace point is always the current
> >>   cpu
> > Are you sure this will always be true?
> 
> It is sure at least now,  the only place to pass 'dev->cpu' is inside
> cpuidle_idle_call,
It was known that cpu_id is always the current cpu with current 
implementation when this got introduced.
But the perf events API must not change back and forth for userspace 
compatibility. Therefore the cpu_id was added in case
that future implementations want to pass info where the current cpu
is not the cpu which is sent to the sleep state.

> smp_processor_id() can't be used safely in preemptible context.
I expect the only side effect that could happen is that if smp_process_id
is interrupted you get the wrong core id on a cpu idle trace event.
This only happens if cpuidle is not used and even then should happen
very rarely, nothing to worry for a debug tool like that.
And it should get fixed if these idle functions get fully integrated into
cpuidle at some point of time.

   Thomas

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-08-22  8:27       ` Thomas Renninger
@ 2011-09-02  7:26         ` Jean Pihet
  2011-09-02  7:38           ` Ming Lei
  0 siblings, 1 reply; 15+ messages in thread
From: Jean Pihet @ 2011-09-02  7:26 UTC (permalink / raw)
  To: Thomas Renninger, Ming Lei
  Cc: rostedt, fweisbec, mingo, linux-kernel, linux-omap, Len Brown

Ming Lei, Thomas,

Sorry if it is a bit late to jump in.

On Mon, Aug 22, 2011 at 10:27 AM, Thomas Renninger <trenn@suse.de> wrote:
> On Saturday, August 20, 2011 04:40:09 AM Ming Lei wrote:
>> Hi,
>>
>> 2011/8/20 Thomas Renninger <trenn@suse.de>:
>> > On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:
>> >> From: Ming Lei <tom.leiming@gmail.com>
>> >>
>> >> This patch removes the 'cpu_id' parameter of the cpu_idle
>> >> trace point, based on the ideas below:
>> >>
>> >> - the cpu_id which is passed to trace point is always the current
>> >>   cpu
>> > Are you sure this will always be true?
>>
>> It is sure at least now,  the only place to pass 'dev->cpu' is inside
>> cpuidle_idle_call,
> It was known that cpu_id is always the current cpu with current
> implementation when this got introduced.
> But the perf events API must not change back and forth for userspace
> compatibility. Therefore the cpu_id was added in case
> that future implementations want to pass info where the current cpu
> is not the cpu which is sent to the sleep state.
Agree. Let's keep the cpu_id field.

>
>> smp_processor_id() can't be used safely in preemptible context.
> I expect the only side effect that could happen is that if smp_process_id
> is interrupted you get the wrong core id on a cpu idle trace event.
> This only happens if cpuidle is not used and even then should happen
> very rarely, nothing to worry for a debug tool like that.
> And it should get fixed if these idle functions get fully integrated into
> cpuidle at some point of time.
>
>   Thomas
>

Regards,
Jean

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle
  2011-09-02  7:26         ` Jean Pihet
@ 2011-09-02  7:38           ` Ming Lei
  0 siblings, 0 replies; 15+ messages in thread
From: Ming Lei @ 2011-09-02  7:38 UTC (permalink / raw)
  To: Jean Pihet
  Cc: Thomas Renninger, rostedt, fweisbec, mingo, linux-kernel,
	linux-omap, Len Brown

Hi,

On Fri, Sep 2, 2011 at 3:26 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>> It was known that cpu_id is always the current cpu with current
>> implementation when this got introduced.
>> But the perf events API must not change back and forth for userspace
>> compatibility. Therefore the cpu_id was added in case
>> that future implementations want to pass info where the current cpu
>> is not the cpu which is sent to the sleep state.
> Agree. Let's keep the cpu_id field.

OK, let's keep it.

How about removing it in clock_enalbe/clock_disable/power_domain_target
as did in [1/3] and [2/3]?  I don't see any usefulness of 'cpu_id' in the tree
trace points.


thanks,
-- 
Ming Lei

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2011-09-02  7:38 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-19 15:04 [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* tom.leiming
2011-08-19 15:04 ` [PATCH 2/3] trace points: power: remove 'cpu_id' from trace_power_domain_target tom.leiming
2011-08-19 15:04 ` [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle tom.leiming
2011-08-19 20:31   ` Thomas Renninger
2011-08-20  2:40     ` Ming Lei
2011-08-20  2:40       ` Ming Lei
2011-08-22  8:27       ` Thomas Renninger
2011-09-02  7:26         ` Jean Pihet
2011-09-02  7:38           ` Ming Lei
2011-08-19 15:14 ` [PATCH 1/3] trace points: power: remove 'cpu_id' from trace_clock_* Steven Rostedt
2011-08-19 15:39   ` Ming Lei
2011-08-19 16:16     ` Arjan van de Ven
2011-08-20  2:44       ` Ming Lei
2011-08-20  2:44         ` Ming Lei
2011-08-20 15:59         ` Arjan van de Ven

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.