Re: [PATCH v4] PM: add statistics debugfs file for suspend to ram
From: Yanmin Zhang
Date: Wed Aug 10 2011 - 21:56:38 EST
On Wed, 2011-08-10 at 23:44 +0200, Pavel Machek wrote:
> > If not using this patch, we have other methods to get info about
> > what device fails. One is to turn on CONFIG_PM_DEBUG, but users
> > would get too much info and testers need recompile the system.
> > In addition, dynamic debug is another good tool to dump debug info.
> > But it still doesn't match our utilization scenario closely.
> > 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.
Thanks for your good comments. To be honest, we did consider the weakness of
the patch before sending out. There is a tradeoff we need balance.
> 1) yes you need parser
> 1a) Yes, you need CONFIG_PM_DEBUG; but that's better than forcing 200
> lines of pure debugging code onto everyone
The new code lines are pretty simple and direct. We don't change any logic of PM.
CONFIG_PM_DEBUG is used mostly to print out debug info timely, not for statistics.
> 2) You can do that. Just check and parse dmesg from userland after
> each resume.
Indeed, there are many methods to do so. But if we implement it in kernel directly,
more developers could benefit from it. And any new kernel patch which touches the logic
would also maintain the consistency between main PM logic and the statistics.
> If dmesg provides too little/too much information, improve loglevels
> so that it is not spammed.
We got very good feedback from internal 1st-line developers and testers. They raised
the requirement and we implement it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/