linux-kernel - Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

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

Date:	Tue, 10 May 2016 12:58:04 -0700
From:	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] intel_pstate: Clarify average performance
 computation

On Tue, 2016-05-10 at 21:21 +0200, Rafael J. Wysocki wrote:
> On Tue, May 10, 2016 at 3:18 AM, Srinivas Pandruvada
> <srinivas.pandruvada@...ux.intel.com> wrote:
> > 
> > On Sat, 2016-05-07 at 01:44 +0200, Rafael J. Wysocki wrote:
> > > 
> > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > 
> > > The core_pct_busy field of struct sample actually contains the
> > > average performace during the last sampling period (in percent)
> > > and not the utilization of the core as suggested by its name
> > > which is confusing.
> > > 
> > > For this reason, change the name of that field to core_avg_perf
> > > and rename the function that computes its value accordingly.
> > > 
> > Makes perfect sense.
> > 
> > > 
> > > Also notice that it would be more useful if it was a "raw"
> > > fraction
> > > rather than percentage, so change its meaning too and update the
> > > code using it accordingly (it is better to change the name of
> > > the field along with its meaning in one go than to make those
> > > two changes separately, as that would likely lead to more
> > > confusion).
> > Due to the calculation the results from old and new method will be
> > similar but not same. For example in one scenario the
> > get_avg_frequency difference is 4.3KHz (printed side by side using
> > both
> > old style using pct and new using fraction)
> > Frequency with old calc: 2996093 Hz
> I guess the above is the new one?
> 
> > 
> > Frequency with old calc: 3000460 Hz
> So the relative difference is of the order of 0.1% and that number is
> not what is used in PID computations.  That's what is printed, but
> I'm
> not sure if that's really that important. :-)

This difference will appear in cpufreq sysfs as their granularity in
KHz for current frequency. But the difference is very small. So I guess
no one will notice.

Thanks,
Srinivas
> 
> Here, the sample.aperf bits lost because the 100 was moved away from
> intel_pstate_calc_busy() would be multiplied by a relatively large
> number to produce the difference that looks significant, but the
> numbers actually used in computations are a few orders of magnitude
> smaller.
> 
> > 
> > How much do you think the performance gain changing fraction vs
> > pct?
> I'm more concerned about latency than about performance.  On HWP, for
> example, the costly multiplication removed by this from the hot path
> is of the order of the half of the work done.
> 
> That said, I can do something to retain the bits in question for as
> long as possible, although the patch will be slightly more
> complicated
> then. :-)
The