lkml.org 
[lkml]   [2013]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2] power: new trace event to print device suspend and resume time
Date
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
>

Hi Joe,

> Hi again Shuah.
>
> A few things:
>
>> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> []
>> + TP_printk("%s %s parent=%s state=%s ops=%s usecs=%lld err=%d\n",
>
> As I wrote before, do not end a TP_printk with "\n",
>
> All TP_printks are self-contained and are not possible
> to use a thing like pr_cont so no newline is ever used.
>
> Use:
>
> TP_printk("%s %s parent=%s state=%s ops=%s usecs=%lld err=%d",

Sorry. Missed that one. Not intentional, just an oversight. :) I should
fix that one.

>
> 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.

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. 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.

I could truncate the string before I pass it to the new tracepoint
routine, however I don't like that idea. One thing I can do is, generate
separate patch that fixes the extra space issue. That would address the
extra space in all cases.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) shuah.kh@samsung.com | (970) 672-0658


\
 
 \ /
  Last update: 2013-07-17 19:21    [W:0.083 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site