lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb17e68f94236b1dd02419ebe01c9f76f6fe2259.camel@intel.com>
Date:   Wed, 6 Feb 2019 15:08:18 +0000
From:   "Pan, Harry" <harry.pan@...el.com>
To:     "pavel@....cz" <pavel@....cz>
CC:     "Brown, Len" <len.brown@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "gs0622@...il.com" <gs0622@...il.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>
Subject: Re: [PATCH] PM / suspend: measure the time of filesystem syncing

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.

-Harry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ