All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Pan, Harry" <harry.pan@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gs0622@gmail.com" <gs0622@gmail.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>
Subject: Re: [PATCH] PM / suspend: measure the time of filesystem syncing
Date: Wed, 6 Feb 2019 17:16:13 +0100	[thread overview]
Message-ID: <20190206161612.GA7868@amd> (raw)
In-Reply-To: <fb17e68f94236b1dd02419ebe01c9f76f6fe2259.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Wed 2019-02-06 15:08:18, Pan, Harry wrote:
> On Tue, 2019-02-05 at 22:23 +0100, Pavel Machek wrote:
> > On Sun 2019-02-03 13:20:07, Harry Pan wrote:
> > > This patch gives the reader an intuitive metric of the time cost by
> > > the kernel issuing a filesystem sync during suspend; although
> > > developer
> > > can guess by the timestamp of next log or enable the ftrace power
> > > event
> > > for manual calculation, this manner is easier to read and benefits
> > > the
> > > automatic script.
> > 
> > Do we really need this functionality?
> > 
> > As you explained, developers can already use next timestamp or
> > ftrace... and this is really not that interesting number.
> 
> The backdrop is some stress test script of suspend/resume, like Chrome
> OS, is designed to program an expected RTC wake-alarm then issue
> suspend command, while in rare case (or buggy software), the filesystem
> sync could cost longer time in seconds, this consumes the alarm budget
> causes suspend aborting, it could be abstruse to production line
> developers to realize it is not a platform issue in terms of drivers
> suspending; given a such metric might make the communication easier,
> this is my intuition.

I'd rather educate other developers that this may happen. dmesg
timestamps should already make it easy to see.

And actually... if you do "time sync" in userspace just before
programing the RTC and suspending, this whole issue should go away.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2019-02-06 16:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-03  5:20 [PATCH] PM / suspend: measure the time of filesystem syncing Harry Pan
2019-02-05 11:55 ` Rafael J. Wysocki
2019-02-06 14:52   ` Pan, Harry
2019-02-05 21:23 ` Pavel Machek
2019-02-06 15:08   ` Pan, Harry
2019-02-06 15:31     ` Pan, Harry
2019-02-06 16:16     ` Pavel Machek [this message]
2019-02-12  0:40       ` Pan, Harry
2019-02-06 14:42 ` Harry Pan
2019-02-06 14:53   ` Pavel Machek
2019-02-12 23:21   ` Rafael J. Wysocki
2019-02-12 23:26     ` Rafael J. Wysocki
2019-02-12 23:35     ` Rafael J. Wysocki
2019-02-06 15:42 ` [PATCH v2] " Harry Pan
2019-02-14  7:16   ` [PATCH v3] " Harry Pan
2019-02-14 11:15   ` Harry Pan
2019-02-19 10:24     ` Rafael J. Wysocki
2019-02-20 16:44       ` Pan, Harry
2019-02-20 21:45         ` Rafael J. Wysocki
2019-02-22 15:56           ` Pan, Harry
2019-02-20 16:12     ` [PATCH v4] " Harry Pan
2019-02-20 16:18     ` Harry Pan
2019-02-22 14:54       ` [PATCH v5] PM / sleep: " Harry Pan
2019-02-24 19:37         ` kbuild test robot
2019-02-24 19:37           ` kbuild test robot
2019-02-24 23:23         ` kbuild test robot
2019-02-24 23:23           ` kbuild test robot
2019-02-22 15:49       ` Harry Pan
2019-02-22 17:54         ` Pavel Machek
2019-02-24  6:17         ` [PATCH v6 1/2] PM / sleep: refactor the filesystems sync to reduce duplication Harry Pan
2019-02-24  6:17           ` [PATCH v6 2/2] PM / sleep: measure the time of filesystems syncing Harry Pan
2019-02-24 20:30             ` kbuild test robot
2019-02-24 20:30               ` kbuild test robot
2019-02-24 21:51             ` kbuild test robot
2019-02-24 21:51               ` kbuild test robot
2019-02-25  9:44             ` [PATCH v7 1/2] PM / sleep: refactor the filesystems sync to reduce duplication Harry Pan
2019-02-25  9:44               ` [PATCH v7 2/2] PM / sleep: measure the time of filesystems syncing Harry Pan
2019-02-25 12:36             ` [PATCH v7 1/2] PM / sleep: refactor the filesystems sync to reduce duplication Harry Pan
2019-02-25 12:36               ` [PATCH v7 2/2] PM / sleep: measure the time of filesystems syncing Harry Pan
2019-03-22  8:21               ` [PATCH v7 1/2] PM / sleep: refactor the filesystems sync to reduce duplication Pavel Machek
2019-02-25  7:33         ` [PATCH v5] PM / sleep: measure the time of filesystem syncing kbuild test robot
2019-02-25  7:33           ` kbuild test robot

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=20190206161612.GA7868@amd \
    --to=pavel@ucw.cz \
    --cc=gs0622@gmail.com \
    --cc=harry.pan@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.