linux-kernel - [PATCH v7 0/1] PM: sleep: Expose last succeeded resumed timestamp in sysfs

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-next>] [day] [month] [year] [list]

Date: Tue, 26 Dec 2023 22:18:07 +0900
From: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
To: "Rafael J . Wysocki" <rafael@...nel.org>,
	Pavel Machek <pavel@....cz>,
	Len Brown <len.brown@...el.com>,
	Randy Dunlap <rdunlap@...radead.org>
Cc: suleiman@...gle.com,
	briannorris@...gle.com,
	Masami Hiramatsu <mhiramat@...nel.org>,
	linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: [PATCH v7 0/1] PM: sleep: Expose last succeeded resumed timestamp in sysfs

Hi,

Here is the 7th version of the patch to expose last succeeded resumed
timestamp in sysfs as /sys/power/suspend_stats/last_success_resume_time.
The previous version is here.

https://lore.kernel.org/all/170245316678.651355.6640896026073025688.stgit@mhiramat.roam.corp.google.com/

This version fixes code comments, sysfs description and patch
description.

On some system like the ChromeOS, the system suspend and resume are
controlled by a power management process. The user-space tasks will be
noticed the suspend and the resume signal from it.
To improve the suspend/resume performance and/or to find regressions,
we would like to know how long the resume processes are taken in kernel
and in user-space.

This patch introduces a last succeeded resumed timestamp (just before
thawing processes) on sysfs which allows us to find when the kernel
resume process successfully done in MONOTONIC clock. Thus user processes
can measure the elapsed time taken by its resume process at any point
in time.

This will help us to detect abnormal value (longer time) process in
the resuming and quickly decide the root cause is in the kernel or
user-space. The kernel side we can use many tools (e.g. printk or
ftrace) but for user-space we need to define the starting point of
the resuming process. Actually, the kernel side needs to use local
clock because the clock subsystem is also suspended. But in that
case, user space can not use that timestamp because the local clock
is not exposed.

So this will be used something like

where_the_user_space_resume_finish() {
	clock_gettime(CLOCK_MONOTONIC, &etime_ts);
	fileread("/sys/.../last_success_resume_time", stime);
	convert_timespec(stime, &stime_ts);
	user_resume_time = timespec_delta(&etime_ts, &stime_ts);
	...
}

Thank you,

---

Masami Hiramatsu (1):
      PM: sleep: Expose last succeeded resumed timestamp in sysfs

 Documentation/ABI/testing/sysfs-power |   11 +++++++++++
 include/linux/suspend.h               |    2 ++
 kernel/power/main.c                   |   15 +++++++++++++++
 kernel/power/suspend.c                |    9 +++++++++
 4 files changed, 37 insertions(+)

--
Masami Hiramatsu (Google) <mhiramat@...nel.org>