Re: [PATCH] PM: add statistics sysfs file for suspend to ram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon 2011-08-08 14:01:04, Greg KH wrote:
> On Mon, Aug 08, 2011 at 10:37:03PM +0200, Rafael J. Wysocki wrote:
> > On Monday, August 08, 2011, Yanmin Zhang wrote:
> > > On Fri, 2011-08-05 at 21:20 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, August 05, 2011, Yanmin Zhang wrote:
> > > > > On Fri, 2011-08-05 at 09:57 +0800, Liu, ShuoX wrote:
> > > > > > > On Thursday, August 04, 2011, Greg KH wrote:
> > > > > > > > On Thu, Aug 04, 2011 at 01:13:38PM +0800, Liu, ShuoX wrote:
> > > > > > > > > >From a906b0b5b4ff3414ceb9fc7a69a3d7c9d66e46b1 Mon Sep 17
> > > > > > > 00:00:00 2001
> > > > > > > > > From: ShuoX Liu <shuox.liu@xxxxxxxxx>
> > > > > > > > > Date: Thu, 28 Jul 2011 10:54:22 +0800
> > > > > > > > > Subject: [PATCH] PM: add statistics sysfs file for suspend to ram.
> > > > > > > >
> > > > > > > > What's this stuff here for?  That's not needed (hint, I would have to
> > > > > > > > edit it out by hand to be able to apply this patch.)
> > > > > > > >
> > > > > > > > Thanks for resending a version that passes checkpatch.pl and could be
> > > > > > > > applied, but all of my previous comments still stand.  This patch, as
> > > > > > > > is, is totally unacceptable.
> > > > > > > 
> > > > > > > Agreed, plus I'd like to know the motivation behind it.  That is, we have
> > > > > > > quite a few debug facilities in that code, so why are they insufficient?
> > > > > Thanks Greg, Rafael. We are changing the patch based on your comments.
> > > > > 
> > > > > > 
> > > > > > Some explanation from Yanmin,
> > > > > > "We are enabling power features on Medfield. Some testers and developers
> > > > > > complain they don't know if system tries suspend-2-ram, and what device 
> > > > > > fails to suspend. They need such info for a quick check. If turning on 
> > > > > > CONFIG_PM_DEBUG, we get too much info and testers need recompile 
> > > > > > the system.
> > > > > Comparing with PC/notebook, a mobile enters/exits suspend-2-ram (we call it s3 on
> > > > > Medfield) far more frequently. If it can't enter suspend-2-ram in time, the power
> > > > > might be used up soon.
> > > > > 
> > > > > We often find sometimes, a device suspend fails. Then, system retries s3 over
> > > > > and over again. As display is off, testers/developers don't know what happens.
> > > > > Teh system 
> > > > > 
> > > > > With the patch, we could know what the bad device is.
> > > > > 
> > > > > The patch doesn't hurt performance as it's just statistics collector.
> > > > > 
> > > > > CONFIG_PM_DEBUG is very useful for finer investigation about what happens behind. What
> > > > > we provide by the patch is to analyze the issues quickly, even by an ordinary tester.
> > > > 
> > > > Well, what about using dynamic debug?
> > > Thanks for the nice pointer. I checked dynamic debug. It's really a good debug tool.
> > > With the dynamic debug:
> > > 1) user need write a user space parser to process the syslog output;
> > > 2) Our testing scenario is we leave the mobile for at least hours. Then, check its status.
> > > No serial console available during the testing. One is because console would be suspended,
> > > and the other is serial console connecting with spi or HSU devices would consume power. These
> > > devices are powered off at suspend-2-ram.
> > > 
> > > Below is an example output of the statistics from my mobile (we are changing the output
> > > from sysfs to debugfs now):
> > > #adb shell cat /sys/power/suspend_stats
> > > success: 5
> > > fail: 1
> > > failed_freeze: 0
> > > failed_prepare: 0
> > > failed_suspend: 1
> > > failed_suspend_noirq: 0
> > > failed_resume: 0
> > > failed_resume_noirq: 0
> > > failed_devs:
> > >   last_failed:	alarm
> > 
> > OK, I see.  Greg, what do you think?
> 
> Files in debugfs like this are fine with me.  If you think the
> information is valid, and useful to people, I have no objection to the
> patch.

Dunno. Just parsing relevant part of dmesg after each suspend should
be enough.

Actually, kernel messages should probably be adjusted so that
filtering for KERN_ERR will get exactly the relevant info... ?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux