[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <170108151076.780347.2482745314490930894.stgit@mhiramat.roam.corp.google.com>
Date: Mon, 27 Nov 2023 19:38:30 +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 v5 0/1] PM: sleep: Expose last succeeded resumed timestamp in sysfs
Hi,
Here is the 5th version of the patch to expose last succeeded resumed
timestamp in sysfs as /sys/power/suspend_stats/last_success_resume_time.
This version is just updated for v6.7-rc3.
This allows us to find when the kernel resume process successfully done
in the sysfs in MONOTONIC clock. Thus we can measure the time taken by
the user space 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 | 10 ++++++++++
include/linux/suspend.h | 2 ++
kernel/power/main.c | 15 +++++++++++++++
kernel/power/suspend.c | 1 +
4 files changed, 28 insertions(+)
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists