On Wed, 2013-07-17 at 16:30 +0000, Shuah Khan wrote:
> On 07/17/2013 10:09 AM, Joe Perches wrote:
> > On Wed, 2013-07-17 at 09:57 -0600, Shuah Khan wrote:
> >> A new trace event is added to pm events to print time it takes to suspend
> >> and
> >> resume a device. It generates trace message that includes device, driver,
> >> parent information in addition to the type of pm ops invoked as well as the
> >> pm event and error status from the pm ops. Example trace below:
> >>
> >> bash-2484 [001] .... 907.330148: device_pm_report_time: backlight
> >> acpi_video0 parent=0000:00:02.0 state=freeze ops=class usecs=0 err=0
> >>
> >> bash-2484 [001] .... 909.906743: device_pm_report_time: backlight
> >> acpi_video0 parent=0000:00:02.0 state=restore ops=class usecs=0 err=0
[]
> > Given the data is in nsecs, why use usecs for the time?
> > I think full resolution would be better.
>
> My intent to was to match the time units to the original pm_print_times.
I don't think that maintaining consistency is
useful in a new facility when you lose precision.
Also the accuracy is suspect as it's calculated with
>>10 rather than an actual divide by 1000.
> Rafael! Do you have any preference as to usecs vs. nsecs?
> > Why are there two spaces after "ops=class"? One would be more normal.
> This one is tough. The ops string that gets generated in conditionals in
> __device_suspend() and device_resume() routines, has an extra space at
> the end. I am not sure why that was done and the subsequent pr_* that
> print that string also depend on that extra space at the end. I don't
> have an easy way to fix it without changing lots of code where this
> string is generated.
I think the easiest way to "fix" it is to change
the TP_printk format to:
TP_printk("%s %s parent=%s state=%s ops=%susecs=%lld err=%d",
> Hence, I chose to leave the extra space in. I also
> didn't want to propagate that assumption that there is an extra space
> into this new tracepoint.
It's a big deal, it just seemed untidy.
There are a couple of places in drivers/base/power/main.c
where info is set to NULL. I didn't look hard to see if
any of those are propagated through to this point, but
there are uses of 'info ?: ""' for some of the logging
messages. That _might_ an issue.
It looks like all the other logging message uses of info
have "%s%s" so that proper word spacing is done when
info is "" or NULL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
