Re: [linux-pm] [PATCH v4] PM: add statistics debugfs file for suspend to ram

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Friday, August 12, 2011, Pavel Machek wrote:
> On Wed 2011-08-10 12:58:54, Greg KH wrote:
> > On Thu, Aug 11, 2011 at 01:22:56AM +0530, Mansoor, Illyas wrote:
> > > static pm_message_t pm_transition;
> > > > > >
> > > > > > @@ -464,8 +465,12 @@ void dpm_resume_noirq(pm_message_t state)
> > > > > >  		mutex_unlock(&dpm_list_mtx);
> > > > > >
> > > > > >  		error = device_resume_noirq(dev, state);
> > > > > > -		if (error)
> > > > > > +		if (error) {
> > > > > > +			suspend_stats.failed_resume_noirq++;
> > > > > > +			dpm_save_failed_step(SUSPEND_RESUME_NOIRQ);
> > > > > > +			dpm_save_failed_dev(dev_name(dev));
> > > > >
> > > > > Please make these statistics conditionally enabled, so on a production system
> > > > > If we need to disable these statistics code we should be able to do so.
> > > > 
> > > > Why, are they taking time or space that is needed for something else?
> > > > What's the downside here of just not always having this enabled?
> > > 
> > > Why have something that is not required/Used?
> > 
> > Because someone might need it and rebuilding a kernel isn't possible on
> > lots of devices.
> 
> Yeah, and someone may need tetris, lets put  it into kernel and enable
> unconditionaly :-(.
> 
> Really, this is just patch to provide dmesg subset, because someone is
> cool enough to hack kernel, but will not just use grep.
> 
> The patch should be just dropped.

And what's the _technical_ reason?

Do you think it's generally wrong to have two different ways of getting
the same debug information from the kernel?

Really, the truth is that suspend debugging is still way too difficult
for the majority of users and I don't quite see a reason to drop patches
that may improve the situation in this area.

Thanks,
Rafael