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. Thanks, Rafael -- 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