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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Jan 2024 18:08:22 -0800
From: Brian Norris <briannorris@...omium.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>, 
	Randy Dunlap <rdunlap@...radead.org>, suleiman@...gle.com, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v7] PM: sleep: Expose last succeeded resumed timestamp in sysfs

On Fri, Jan 19, 2024 at 1:08 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Wed, Jan 17, 2024 at 1:07 AM Masami Hiramatsu <mhiramat@...nelorg> wrote:
> >
> > Gently ping,
> >
> > I would like to know this is enough or I should add more info/update.
>
> I still am not sure what this is going to be useful for.
>
> Do you have a specific example?

Since there seems to be some communication gap here, I'll give it a try.

First, I'll paste the key phrase of its use case from the cover letter:

  "we would like to know how long the resume processes are taken in kernel
  and in user-space"

This is a "system measurement" question, for use in tests (e.g., in a
test lab for CI or for pre-release testing, where we suspend
Chromebooks, wake them back up, and measure how long the wakeup took)
or for user-reported metrics (e.g., similar statistics from real
users' systems, if they've agreed to automatically report usage
statistics, back to Google). We'd like to know how long it takes for a
system to wake up, so we can detect when there are problems that lead
to a slow system-resume experience. The user experience includes both
time spent in the kernel and time spent after user space has thawed
(and is spending time in potentially complex power and display manager
stacks) before a Chromebook's display lights back up.

If I understand the whole of Masami's work correctly, I believe we're
taking "timestamps parsed out of dmesg" (or potentially out of ftrace,
trace events, etc.) to measure the kernel side, plus "timestamp
provided here in CLOCK_MONOTONIC" and "timestamp determined in our
power/display managers" to measure user space.

Does that make sense? Or are we still missing something "specific" for
you? I could give code pointers [1], as it's all open source. But I'm
not sure browsing our metric-collection code would help understanding
any more than these explanations.

(TBH, this all still seems kinda odd to me, since parsing dmesg isn't
a great way to get machine-readable information. But this at least
serves to close some gaps in measurement.)

Brian

[1] e.g., https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/power_manager/powerd/metrics_collector.cc;l=294;drc=ce8075df179c4f8b2f4e4c4df6978d3df665c4d1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ