public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Mario Limonciello <mario.limonciello@amd.com>,
	Sven van Ashbrook <svenva@chromium.org>,
	Rafael J Wysocki <rafael@kernel.org>,
	linux-pm@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
	John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>
Cc: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
	S-k Shyam-sundar <Shyam-sundar.S-k@amd.com>,
	rrangel@chromium.org, Rajat Jain <rajatja@google.com>,
	David E Box <david.e.box@intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [RFC v2 1/3] PM: Add a sysfs files to represent sleep duration
Date: Mon, 14 Nov 2022 00:53:42 +0100	[thread overview]
Message-ID: <871qq6tnqx.ffs@tglx> (raw)
In-Reply-To: <20221110064723.8882-2-mario.limonciello@amd.com>

On Thu, Nov 10 2022 at 00:47, Mario Limonciello wrote:

'Add a sysfs files'?

Can you please decide whether that's 'a file' or 'multiple files'?

> Both AMD and Intel SoCs have a concept of reporting whether the hardware
> reached a hardware sleep state over s2idle as well as how much
> time was spent in such a state.

Nice, but ...

> This information is valuable to both chip designers and system designers
> as it helps to identify when there are problems with power consumption
> over an s2idle cycle.
>
> To make the information discoverable, create a new sysfs file and a symbol
> that drivers from supported manufacturers can use to advertise this
> information. This file will only be exported when the system supports low
> power idle in the ACPI table.
>
> In order to effectively use this information you will ideally want to
> compare against the total duration of sleep, so export a second sysfs file
> that will show total time. This file will be exported on all systems and
> used both for s2idle and s3.

The above is incomprehensible word salad. Can you come up with some
coherent explanation of what you are trying to achieve please?

> +void pm_set_hw_state_residency(u64 duration)
> +{
> +	suspend_stats.last_hw_state_residency = duration;
> +}
> +EXPORT_SYMBOL_GPL(pm_set_hw_state_residency);
> +
> +void pm_account_suspend_type(const struct timespec64 *t)
> +{
> +	suspend_stats.last_suspend_total += (s64)t->tv_sec * USEC_PER_SEC +
> +						 t->tv_nsec / NSEC_PER_USEC;

Conversion functions for timespecs to scalar nanoseconds exist for a
reason. Why does this need special treatment and open code it?

> +}
> +EXPORT_SYMBOL_GPL(pm_account_suspend_type);

So none of these functions has any kind of documentation. kernel-doc
exists for a reason especially for exported functions.

That said, what's the justification to export any of these functions at
all? AFAICT pm_account_suspend_type() is only used by builtin code...

> +static umode_t suspend_attr_is_visible(struct kobject *kobj, struct attribute *attr, int idx)
> +{
> +	if (attr != &last_hw_state_residency.attr)
> +		return 0444;
> +#ifdef CONFIG_ACPI
> +	if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)
> +		return 0444;
> +#endif
> +	return 0;
> +}
> +
>  static const struct attribute_group suspend_attr_group = {
>  	.name = "suspend_stats",
>  	.attrs = suspend_attrs,
> +	.is_visible = suspend_attr_is_visible,

How is this change related to the changelog above? We are not hiding
subtle changes to the existing code in some conglomorate patch. See
Documentation/process/...

> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -24,6 +24,7 @@
>  #include <linux/compiler.h>
>  #include <linux/audit.h>
>  #include <linux/random.h>
> +#include <linux/suspend.h>
>  
>  #include "tick-internal.h"
>  #include "ntp_internal.h"
> @@ -1698,6 +1699,7 @@ static void __timekeeping_inject_sleeptime(struct timekeeper *tk,
>  	tk_set_wall_to_mono(tk, timespec64_sub(tk->wall_to_monotonic, *delta));
>  	tk_update_sleep_time(tk, timespec64_to_ktime(*delta));
>  	tk_debug_account_sleep_time(delta);
> +	pm_account_suspend_type(delta);

That function name is really self explaining - NOT !

     pm_account_suspend_type(delta);

So this will account a suspend type depending on the time spent in
suspend, right?

It's totally obvious that the suspend type (whatever it is) depends on
the time delta argument... especially when the function at hand has
absolutely nothing to do with a type:

> +void pm_account_suspend_type(const struct timespec64 *t)
> +{
> +	suspend_stats.last_suspend_total += (s64)t->tv_sec * USEC_PER_SEC +
> +						 t->tv_nsec / NSEC_PER_USEC;
> +}

Sigh....

Thanks,

        tglx

  reply	other threads:[~2022-11-13 23:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10  6:47 [RFC v2 0/3] Introduce infrastructure to report time in hardware sleep state Mario Limonciello
2022-11-10  6:47 ` [RFC v2 1/3] PM: Add a sysfs files to represent sleep duration Mario Limonciello
2022-11-13 23:53   ` Thomas Gleixner [this message]
2022-11-14 19:12     ` Limonciello, Mario
2022-11-15 10:32       ` Hans de Goede
2022-11-15 14:13         ` Limonciello, Mario
2022-11-17  2:40           ` Box, David E
2022-11-14  7:12   ` Greg KH
2022-11-15 14:45   ` Rafael J. Wysocki
2022-11-15 15:17     ` Limonciello, Mario
2022-11-15 16:35       ` Rafael J. Wysocki
     [not found]         ` <CAHQZ30BCXtyJ9qqHHX5eztXbgA_A8yH48+AQVMCB64CXjqE+hQ@mail.gmail.com>
2022-11-15 17:26           ` Limonciello, Mario
2022-11-15 17:52             ` Rafael J. Wysocki
2022-11-15 17:58               ` Limonciello, Mario
2022-11-15 19:08                 ` Rafael J. Wysocki
2022-11-10  6:47 ` [RFC v2 2/3] platform/x86/amd: pmc: Report duration of time in deepest hw state Mario Limonciello
2022-11-10  6:47 ` [RFC v2 3/3] platform/x86/intel/pmc: core: Report duration of time in HW sleep state Mario Limonciello
2022-11-13 23:57   ` Thomas Gleixner
2022-11-14 19:06     ` Limonciello, Mario

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qq6tnqx.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=david.e.box@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=irenic.rajneesh@gmail.com \
    --cc=jstultz@google.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=pavel@ucw.cz \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rajatja@google.com \
    --cc=rrangel@chromium.org \
    --cc=sboyd@kernel.org \
    --cc=svenva@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox