linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Naveen Krishna Ch <naveenkrishna.ch@gmail.com>,
	Naveen Krishna Chatradhi <nchatrad@amd.com>,
	linux-hwmon@vger.kernel.org
Subject: Re: [PATCH 1/3 v7] hwmon: Add amd_energy driver to report energy counters
Date: Wed, 27 May 2020 18:12:15 +0300 (MSK)	[thread overview]
Message-ID: <alpine.LNX.2.20.13.2005271755070.18802@monopod.intra.ispras.ru> (raw)
In-Reply-To: <20200527144838.GA209591@roeck-us.net>

On Wed, 27 May 2020, Guenter Roeck wrote:

> > I'm not exactly complaining, I'm proposing a solution: at probe time, populate
> > prev_value members with MSR values instead of zeros. That way, the module will
> > correctly count energy over the time it's been loaded. It can be unloaded and
> > reloaded freely, and doing so would allow to easily measure energy across large
> > spans of time, which sounds like an improvement.
> > 
> That would ignore energy accumulated from before the driver was loaded, and
> would thus trigger another set of complaints.

That doesn't sound right. There's no way for the driver to be sure that the
counters did not wrap around before it was loaded. Here's a few scenarios
how such wraparound is possible:

- while the user was messing in the bootloader for a few minutes
- if the user kexec'd a new kernel
- if the counters were not reset during a warm reboot

Ignoring initial values of the counters is generally the right thing to do.
In the specific circumstances when the user wants to measure energy used
since machine power-up, and they know the boot happened so quick the counters
did not wrap around, they can easily script that with e.g. the rdmsr tool.
Or perhaps the driver could pr_info the initial values at probe time.

Have such complaints already appeared in practice?

Also note that documentation doesn't promise that counters start from zero
at power-up time, although that's of course a natural assumption.


> A slight improvement might be to add up core energy counters when loading
> the driver, compare it against the package counter, and pick the larger
> value for the initial package counter(s). This would at least ensure that
> the package counter is never less than the sum of the core counters.

No, fudging the initial reading like this wouldn't help, because I was
pointing out how core counters increment quicker than the package counter;
i.e. even if the kernel fudged the initial values, they would still grow
contradictory quick enough (on some workloads).

Alexander

  reply	other threads:[~2020-05-27 15:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 15:50 [PATCH 1/3 v7] hwmon: Add amd_energy driver to report energy counters Naveen Krishna Chatradhi
2020-05-19 15:50 ` [PATCH 2/3 v7] hwmon: (amd_energy) Add documentation Naveen Krishna Chatradhi
2020-05-19 15:50 ` [PATCH 3/3 v7] MAINTAINERS: add entry for AMD energy driver Naveen Krishna Chatradhi
2020-05-22 13:26 ` [PATCH 1/3 v7] hwmon: Add amd_energy driver to report energy counters Guenter Roeck
2020-05-22 14:19   ` Naveen Krishna Ch
2020-05-26 22:37     ` Alexander Monakov
2020-05-27  3:03       ` Naveen Krishna Ch
2020-05-27  6:59         ` Alexander Monakov
2020-05-27 10:35           ` Naveen Krishna Ch
2020-05-27 13:28             ` Guenter Roeck
2020-05-27 14:08               ` Alexander Monakov
2020-05-27 14:42                 ` Naveen Krishna Ch
2020-05-27 15:15                   ` Guenter Roeck
2020-05-27 15:25                     ` Alexander Monakov
2020-05-27 15:35                       ` Guenter Roeck
2020-05-27 14:48                 ` Guenter Roeck
2020-05-27 15:12                   ` Alexander Monakov [this message]
2020-05-27 15:33                     ` Guenter Roeck
2020-05-27 16:41                       ` Alexander Monakov
2020-05-27 16:57                         ` Guenter Roeck
2020-05-27 17:12                           ` Alexander Monakov
2020-05-27 16:59             ` Alexander Monakov
2020-05-28  4:11               ` Naveen Krishna Ch
2020-06-10 20:21                 ` Alexander Monakov
2020-06-16 14:46                   ` Chatradhi, Naveen Krishna
2020-06-16 14:53                     ` Guenter Roeck
2020-06-16 14:57                       ` Naveen Krishna Ch

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=alpine.LNX.2.20.13.2005271755070.18802@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=naveenkrishna.ch@gmail.com \
    --cc=nchatrad@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).