Re: [PATCH 3/3] trace points: power: remove 'cpu_id' from trace_cpu_idle

Hi,

2011/8/20 Thomas Renninger [off-list ref]:

On Friday, August 19, 2011 05:04:04 PM tom.leiming@gmail.com wrote:

quoted

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.

quoted

- 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