On Wed, Feb 13, 2019 at 12:21 AM Rafael J. Wysocki wrote:
>
> On Wed, Feb 6, 2019 at 4:57 PM 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 n
On Wed, Feb 13, 2019 at 12:21 AM Rafael J. Wysocki wrote:
>
> On Wed, Feb 6, 2019 at 4:57 PM 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 n
On Wed, Feb 6, 2019 at 4:57 PM 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
>
> 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.
>
>
I agree w/ you on both comments basic
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
> > >
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
> 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
> caus
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
On Wed 2019-02-06 22:42:57, 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 manne
On Tue, 2019-02-05 at 12:55 +0100, Rafael J. Wysocki wrote:
>
> > + ktime_t start, end, elapsed;
>
> Why do you need three vars here? One should be sufficient.
...
> > + start = ktime_get_boottime();
>
> Why _boottime()?
>
Yes, I agree both comments.
BTW, The initial idea came from proces
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 manne
On Sunday, February 3, 2019 6:20:07 AM CET 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 calculat
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
13 matches
Mail list logo
