On 10/26/2010 1:38 PM, Rafael J. Wysocki wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 2:08 PM, Rafael J. Wysocki<rjw@xxxxxxx> wrote:
On Tuesday, October 26, 2010, Pierre Tardy wrote:
On Tue, Oct 26, 2010 at 12:58 PM, Peter Zijlstra<peterz@xxxxxxxxxxxxx> wrote:
On Tue, 2010-10-26 at 11:56 -0500, Pierre Tardy wrote:
+ trace_runtime_pm_usage(dev, atomic_read(&dev->power.usage_count)+1);
atomic_inc(&dev->power.usage_count);
That's terribly racy..
I know. I'm not proud of this.. As I said, this is preliminary patch.
We dont really need to have this prev_usage. This is just for debug.
It mayprobably endup with something like:
atomic_inc(&dev->power.usage_count);
+ trace_power_device_usage(dev);
Well, please tell me what you're trying to achieve.
Please see attached the kind of pytimechart output I'm trying to
achieve (yes, this chart is not coherent, seems I'm still missing some
traces)
We basically want to have a trace point eachtime the usage_counter
changes, so that I can display nice timecharts, and Arjan can have the
comm of the process that eventually generated the rpm_get, in order to
pinpoint it in powertop.
What you dont see in the above two lines is that
trace_power_device_usage(dev); actually reads the usage_count, as well
as the driver and device name.
I'm afraid that for this to really work you'd need to put usage_count under a
spinlock along with your trace point, which I'm not really sure I like.
Besides, I'm not really sure the manipulations of usage_count are worth
tracing.
what's most interesting is the 0->1 and 1->0 transitions.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
