From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Liu, ShuoX" <shuox.liu@intel.com>,
yanmin_zhang@linux.intel.com, Greg KH <gregkh@suse.de>,
"linux-pm@lists.linux-foundation.org"
<linux-pm@lists.linux-foundation.org>,
"Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH] PM: add statistics sysfs file for suspend to ram
Date: Thu, 11 Aug 2011 21:48:08 +0200 [thread overview]
Message-ID: <201108112148.08220.rjw@sisk.pl> (raw)
In-Reply-To: <20110810222725.GA2012@elf.ucw.cz>
On Thursday, August 11, 2011, Pavel Machek wrote:
> On Tue 2011-08-09 00:09:42, Rafael J. Wysocki wrote:
> > On Monday, August 08, 2011, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > > > 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.
> > > ...
> > > > Not in the case described by Yanmin.
> > >
> > > Really? I see the description above.
> > >
> > > Yes, they'd need to set up syslog to only log >= KERN_ERR, then parse
> > > the (small) results. Even hours worth of suspends should not cause
> > > _that_ many errors.
> > >
> > > Serial console is irrelevant. You need live machine to dump dmesg, but
> > > again, you need live machine to access debugfs, too.
> >
> > This sounds like substantial overhead to collect statistics that we can
> > collect at a much lower cost in the kernel.
>
> That's always the case, right? Everyone wants different subsets of
> syslog, and doing selection in kernel is always lowest overhead.
>
> > The patch isn't very intrusive and rather straightforward.
>
> No, it is not _too_ bad; but
>
> 1) the code stays there when not debugging
Fine. I don't really think that matters a lot, does it?
> 2) different users want different syslog subsets. Putting all the
> "interesting" subsets into /sys/debug/my_syslog_subset just does not
> seem like a way to go.
I don't agree with such a broad generalization. From the system management
point of view suspend is rather special and the information the patch
collects is useful and would require substantial overhead to collect from
user space (and I can imagine test setups where it can't be collected from
user space).
I think that the explanation why dynamic debug isn't sufficient provided
by Yanmin is convincing. Apparently, you think it isn't, but you haven't
proven him wrong yet.
Rafael
next prev parent reply other threads:[~2011-08-11 19:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 5:13 [PATCH] PM: add statistics sysfs file for suspend to ram Liu, ShuoX
2011-08-04 5:27 ` Greg KH
2011-08-04 9:32 ` Rafael J. Wysocki
2011-08-05 1:57 ` Liu, ShuoX
2011-08-05 3:19 ` Yanmin Zhang
2011-08-05 19:20 ` Rafael J. Wysocki
2011-08-08 3:48 ` Yanmin Zhang
2011-08-08 20:37 ` Rafael J. Wysocki
2011-08-08 21:01 ` Greg KH
2011-08-08 21:05 ` Pavel Machek
2011-08-08 21:14 ` Rafael J. Wysocki
2011-08-08 21:54 ` Pavel Machek
2011-08-08 22:09 ` Rafael J. Wysocki
2011-08-10 22:27 ` Pavel Machek
2011-08-11 19:48 ` Rafael J. Wysocki [this message]
2011-08-04 19:05 ` Len Brown
2011-08-04 19:17 ` Randy Dunlap
2011-08-04 19:50 ` Rafael J. Wysocki
-- strict thread matches above, loose matches on Subject: below --
2011-08-04 5:09 Liu, ShuoX
2011-08-04 5:16 ` Greg KH
2011-08-04 5:17 ` Greg KH
2011-08-03 17:37 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201108112148.08220.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=gregkh@suse.de \
--cc=len.brown@intel.com \
--cc=linux-pm@lists.linux-foundation.org \
--cc=pavel@ucw.cz \
--cc=shuox.liu@intel.com \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).