[PATCH] csstoh.sh shell script fixes cross compiling issues
by Thomas Waldecker
From: Thomas Waldecker <thomas.waldecker(a)tqs.de>
Added the csstoh.sh shell script from Igor Zhbanov found here:
http://lists.01.org/pipermail/powertop/2012-July/000151.html
also patched the Makefile.am to use the csstoh.sh script.
The compiled csstoh binary doesn't work for cross compiling,
however Igors Patch never got applied upstream.
---
src/Makefile.am | 8 +++-----
src/csstoh.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 5 deletions(-)
create mode 100755 src/csstoh.sh
diff --git a/src/Makefile.am b/src/Makefile.am
index f60426a..a53d942 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,9 +1,6 @@
AUTOMAKE_OPTIONS = subdir-objects
ACLOCAL_AMFLAGS = -I ../m4
-noinst_PROGRAMS = csstoh
-csstoh_SOURCES = csstoh.c
-
sbin_PROGRAMS = powertop
nodist_powertop_SOURCES = css.h
@@ -48,6 +45,7 @@ AM_LDFLAGS = $(LIBS) $(NCURSES_LIBS) $(PCIUTILS_LIBS) $(LIBNL_LIBS) $(LIBZ_LIBS)
BUILT_SOURCES = css.h
CLEANFILES = css.h
-css.h: csstoh powertop.css
- ./csstoh "$(srcdir)"/powertop.css css.h
+css.h: powertop.css
+ chmod +x ./csstoh.sh
+ ./csstoh.sh "$(srcdir)"/powertop.css css.h
diff --git a/src/csstoh.sh b/src/csstoh.sh
new file mode 100755
index 0000000..5918d12
--- /dev/null
+++ b/src/csstoh.sh
@@ -0,0 +1,45 @@
+#!/bin/bash
+#
+# This program file is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; version 2 of the License.
+#
+# This program is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program in a file named COPYING; if not, write to the
+# Free Software Foundation, Inc,
+# 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301 USA
+# or just google for it.
+#
+# Written by Igor Zhbanov<i.zhbanov at samsung.com>
+
+
+if [ $# -lt 2 ]; then
+ echo "Usage: csstoh.sh cssfile header.h"
+ exit 1
+fi
+
+if [ ! -r $1 ]; then
+ echo "Can't find file $1"
+ exit 1
+fi
+
+if ! echo -n>$2; then
+ echo "Can't open file $2 for writing."
+ exit 1
+fi
+
+echo "#ifndef __INCLUDE_GUARD_CCS_H">> $2
+echo "#define __INCLUDE_GUARD_CCS_H">> $2
+echo>> $2
+echo "const char css[] = ">> $2
+
+sed -r 's/^(.*)$/\t\"\1\\n\"/' $1>> $2
+
+echo ";">> $2
+echo "#endif">> $2
--
1.7.9.5
9 years, 4 months
[FYI][RFC][PATCH 0/2] MALI GPU profiling support
by Igor Zhbanov
This patch-set adds the ability of profiling MALI GPU in Powertop.
Disclaimer:
This patch-set is far from perfect and I know it. ;-)
It is just an initial review attempt.
Tha MALI GPU profiling patch is written in C-style because initially
there was a C-program. Yes, it is possible to rewrite is in C++ if needed.
But now I would know whether it fits into the Powertop at all?
And here is some explanation of what inside the box.
*** MALI GPU profiling with PowerTOP ***
** MALI GPU **
Mali GPU consists of several Geometry Processor units (GP) and Pixel Processor
units (PP). For example, MALI 400 MP GPU has one Geometry Processor (GP0) and
four Pixel Processors (PP0, PP1, PP2 and PP3). Also MALI GPU may contain other
units such as L2 cache. But now I don't know how to profile them.
* PseudoWatt definition *
Consumed power approximately can be computed as this [1]:
2
P = CV f, /* P = C*V*V*f */
(where C is capacitance, V is voltage and f is frequency).
We don't need exact Watts so we consider that 1 PW (PseudoWatt) is consumed
running one GPU unit (GPx or PPx) on 266 MHz and 1 Volt. So I consider
capacitance equal to 1 / 266 000 000.
** Event types **
There are two types of profiling events visible from user-space applications:
performance counters and trace events.
* Performance counters *
There are two performance counter registers per each GPx, PPx or L2 unit in
the MALI GPU. Each register can count events of specified type. One can
specify the type of interesting event by writing a value in the corresponding
performance counter source register. Event types can be found in technical
reference manual for MALI GPU.
Such events are counted on per GPU basis because GPU has no information what
process runs specified task. So we cannot use these performance counters to
measure per-process activity. Also only two types of events can be counted
simultaneously for any GPU unit because there are only two counter registers
per unit.
* Trace events *
MALI GPU kernel module provide events information by the means of pseudo-files
in /sys filesystem (actual for r3p0 driver version). There are two exclusive
ways to get profiling events from kernel module -- Linux trace points and
internal profiling format. The way which will be used is defined at the
compile time. In the file drivers/media/video/samsung/mali_r3p0/Makefile there
is variable USING_INTERNAL_PROFILING that is set to 1 when internal profiling
mode is used and is set to 0 when trace points are used. By default it is set
to 1 (internal profiling mode).
* Trace points *
In trace points mode MALI GPU events are available through the standard
mechanism of Linux kernel trace points. To grab MALI trace events one should
write mali_timeline_event string to the file /sys/kernel/debug/tracing/set
event. Then it is possible to read events from the file
/sys/kernel/debug/tracing/trace_pipe.
This trace point is defined in the file
drivers/media/video/samsung/mali_r3p0/linux/mali_linux.trace.h in Linux kernel
source tree [2]. As you may see each event has event identifier (event_id)
meaning the type of event and five event parameters (d0 through d4) containing
additional information. Not all parameters are required for all types of
events. For that events these parameters are set to zero.
As you may see by the next line only event identifier provided to user space
by the means of trace points:
TP_printk("event=%d", __entry->event_id)
It is not suitable because we need to know more information for proper event
handling.
The other way of getting trace events information is the sys_perf_event_open
system call. But MALI GPU driver doesn't provide all needed events in this
way. In particular such events as voltage and frequency change are available
only by using internal profiling method.
So we have to use internal profiling method in PowerTOP (or we could enhance
MALI GPU driver written by ARM to provide all needed events via trace points).
* Internal profiling *
Internal profiling is the method provided by MALI GPU kernel module allowing
to collect more information about events (although there are no restrictions
preventing sending this information via trace points). This facility is
controlled by pseudo-files in /sys file-system.
To enable this facility to work one should write character 1 to the file
/sys/kernel/debug/mali/profiling/proc/default/enable. To disable profiling
write character 0.
When profiling is turned on it is possible to enable or disable events
recording by writing characters 1 or 0, respectively, to the file
/sys/kernel/debug/mali/profiling/record.
When event recording is on events information is collected in driver's
internal buffer. And when event recording is off this information is available
in the file /sys/kernel/debug/mali/profiling/events. When event recording
is on this file is empty.
* Event format *
Each event is reported as a text line consisting of seven decimal numbers like
this:
1329701288752682877 34013184 0 0 4294967295 0 0
First number is the UNIX time with nanosecond resolution (number of
nanoseconds since Jan 1-st of 1970).
Second number is the event identifier in the following format:
Bit number: 31 - 28 27 - 24 23 - 16 15 - 00
Type of field: Reserved Type Channel Data
The Type field denotes event type. This field can accept the following values:
Value Type Description
0 SINGLE Single event
1 START Start rendering job
2 STOP Stop rendering job
3 SUSPEND
4 RESUME
The Channel field denotes event channel or source. This field can accept the
following values:
Value Channel Description
00 SOFTWARE Events came from user-space
01 GP0 Geometry Processor
05 PP0 Pixel Processors
06 PP1
07 PP2
08 PP3
09 PP4
10 PP5
11 PP6
12 PP7
21 GPU GPU Core
The Data field contains event subtype which can be used to concretize
particular event type. The meaning of this field depends on the value of Type
field.
For events of type SINGLE from SOFTWARE channel this field can accept the
following values:
Value Type Description
0 NONE (Unused?)
1 EGL_NEW_FRAME (Unused?)
2 FLUSH (Unused?)
3 EGL_SWAP_BUFFERS (Unused?)
4 GPU_FREQ GPU frequency was changed
5 GPU_VOLTS GPU voltage was changed
6 GLOBAL_TRY_LOCK
7 GLOBAL_LOCK
8 GLOBAL_UNLOCK
9 VBLANK_VSYNC
For events of type SINGLE from GP0 and PP0 through PP7 channels this field can
accept the following values:
Value Type
0 NONE
1 INTERRUPT
2 FLUSH
And for events of type SINGLE from GPU channel this field can accept following
value:
Value Type Description
10 FREQ_VOLT_CHANGE GPU frequency and voltage was changed
Data fields d0 through d4 contains data specific to particular event. If some
fields are not used it's set to zero.
** Computing the power consumption **
* Useful events *
There are several types of events that are used to calculate power
consumption. First of all it is rendering job starting and stopping events.
For START event PowerTop records PID of the process started the job, the time
of start and GPU unit name the job is running on (PP0, PP1,... PP7). PID of
the process can be found in the field d0.
When PowerTOP receives the STOP event, this mean that rendering job was
stopped and it is possible to calculate its duration. This duration will be
used to calculate power consumption.
Also there are three types of events related to GPU core frequency and/or
voltage change. PowerTOP tracks current values of frequency and voltage.
* Power consumption *
Power consumption of the GPU depends on frequency and voltage the GPU core is
operating on. When voltage and/or frequency was changed PowerTOP split current
running tasks if any into two (one with old values and another with new
values). So for each rendering task PowerTOP knows its duration, frequency and
voltage of the GPU core and the PID of the process started this task. That is
power consumed for particular task rendering can be computed using the formula
above. By adding together power consumed by individual tasks PowerTOP can
calculate total power consumption for each process.
The MALI GPU power consumption information can be found in a table named
"Overview of MALI GPU power consumers" in PowerTOP HTML-report.
** Deficiencies **
* Process names *
Sometimes PowerTOP cannot properly display process name when it was started
after PowerTOP start and was terminated before PowerTOP finished to work. This
can happen because process could generate only GPU-related events (and none of
scheduler-related events) and GPU-related events contains only PID of process
(not the command line or application name). And since the process was
terminated early, PowerTOP cannot resolve process name through the /proc
file-system because at that time there will be no entry for terminated
process.
This happen because of PowerTOP design. After start it asks the kernel to
collect events, then sleeps some seconds and reads events from the kernel and
process it. Some events (scheduler-related) contains process name and its
command line, and others not (e.g. GPU-related). So if some process doesn't
generated scheduler-related events and terminated before PowerTOP wakes after
sleep, then the PowerTOP can nowhere get information about process.
To solve this problem I have modified PowerTOP so it constantly monitors
/proc file-system for the new processes. And when it sees the new one it
collects process' information. PowerTOP monitors it once in a second. I think
it is a good compromise between CPU load and frequent information collecting.
The probability that some process (living less than a second) escapes
monitoring still exist, but it is much lower than in current version. At the
worst case (when process generate only GPU-related events during its very
short life) PowerTOP will display only PID for that process.
Anyway such an elusive process will not generate enough power consumption
to worry about.
* Voltage/frequency independent change *
There are three type of events from MALI kernel module related to frequency or
voltage changing:
the voltage was changed,
the frequency was changed,
both of the voltage and the frequency was changed.
It is impossible to change only the frequency or only the voltage of CPU core.
Both parameters are changed at the same time. But the driver can report any
set of these events in any order. Having a table with pairs of allowed
frequency/voltage values it is possible to deduce one value from another. But
that table will be GPU dependent and we don't have an information about all of
MALI GPU chips.
Now it is possible a situation when PowerTOP sees an event of frequency or
voltage change after some job was started. PowerTOP will split the running
task, and the second half of the task will have slightly incorrect value of
frequency or voltage (old frequency with new voltage or vice verse). This may
lead to tiny computational errors.
* Initial voltage and frequency values *
When PowerTOP starts on system with display turned on and some graphical
applications already running, there is a possibility for situation where some
rendering job will be started before PowerTOP grabs the first voltage or
frequency setting event. So PowerTOP will be unaware of current frequency
and/or voltage value. Because of this it is impossible to correctly calculate
power consumption for that task because it is impossible to ask the driver
about current frequency and voltage. And in the current version PowerTOP drops
jobs before first voltage or frequency change event (such events are frequent
enough, so it's not a problem). It is possible to use some default value but
it will be GPU-dependent and we don't know what value to use.
Links:
[1] http://en.wikipedia.org/wiki/CPU_power_dissipation
[2] You can study MALI GPU driver for example in kernel for
Galaxy SIII phone found in archive named
GT-I9300_JB_Opensource_Update6.zip
on the site http://opensource.samsung.com/
Igor Zhbanov (2):
Introducing process scanner facility
MALI GPU profiling support
src/Makefile.am | 2 +
src/main.cpp | 17 +-
src/mali-internal-events/mali-events.h | 143 +++
src/mali-internal-events/mali-internal-events.cpp | 1279 +++++++++++++++++++++
src/mali-internal-events/proc-scan.cpp | 316 +++++
src/mali-internal-events/proc-scan.h | 59 +
src/process/process.cpp | 43 +
7 files changed, 1857 insertions(+), 2 deletions(-)
create mode 100644 src/mali-internal-events/mali-events.h
create mode 100644 src/mali-internal-events/mali-internal-events.cpp
create mode 100644 src/mali-internal-events/proc-scan.cpp
create mode 100644 src/mali-internal-events/proc-scan.h
--
1.7.5.4
9 years, 6 months
[PATCH] Allow frequency stats when cpuidle is not enabled
by Rajagopal Venkat
Powertop fails to display frequency stats when cpuidle subsystem
is not enabled. Fix it.
Signed-off-by: Rajagopal Venkat <rajagopal.venkat(a)linaro.org>
---
src/cpu/cpu_linux.cpp | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/cpu/cpu_linux.cpp b/src/cpu/cpu_linux.cpp
index d6caf45..b8dbbc5 100644
--- a/src/cpu/cpu_linux.cpp
+++ b/src/cpu/cpu_linux.cpp
@@ -63,7 +63,7 @@ void cpu_linux::measurement_start(void)
dir = opendir(filename);
if (!dir)
- return;
+ goto cpufreq;
/* For each C-state, there is a stateX directory which
* contains a 'usage' and a 'time' (duration) file */
@@ -112,6 +112,7 @@ void cpu_linux::measurement_start(void)
}
closedir(dir);
+cpufreq:
last_stamp = 0;
for (i = 0; i < children.size(); i++)
@@ -149,7 +150,7 @@ void cpu_linux::measurement_end(void)
dir = opendir(filename);
if (!dir)
- return;
+ goto cpufreq;
/* For each C-state, there is a stateX directory which
* contains a 'usage' and a 'time' (duration) file */
@@ -188,6 +189,7 @@ void cpu_linux::measurement_end(void)
}
closedir(dir);
+cpufreq:
sprintf(filename, "/sys/devices/system/cpu/cpu%i/cpufreq/stats/time_in_state", number);
file.open(filename, ios::in);
--
1.7.11.3
9 years, 7 months
[PATCH] Use PACKAGE_VERSION for POWERTOP_VERSION
by Namhyung Kim
It was missed to update POWERTOP_VERSION macro so that the
new v2.2 release still shows v2.1 string on the header of
ncurses window. Convert to use PACKAGE_VERSION macro which
set by autotools to the AC_INIT version so that it cannot
be missed anymore.
Signed-off-by: Namhyung Kim <namhyung(a)gmail.com>
---
src/lib.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib.h b/src/lib.h
index 8cf4632..209421a 100644
--- a/src/lib.h
+++ b/src/lib.h
@@ -35,8 +35,8 @@
#define _(STRING) gettext(STRING)
-#define POWERTOP_VERSION "v2.1"
-#define POWERTOP_SHORT_VERSION "2.1"
+#define POWERTOP_VERSION "v"PACKAGE_VERSION
+#define POWERTOP_SHORT_VERSION PACKAGE_VERSION
extern int get_max_cpu(void);
--
1.7.9.2
9 years, 7 months
[PATCH] report: fixed crash when writing report to RO filesystem
by Jaroslav Škarvada
Signed-off-by: Jaroslav Škarvada <jskarvad(a)redhat.com>
---
src/report/report.cpp | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/report/report.cpp b/src/report/report.cpp
index 51bc6a7..c018bb1 100644
--- a/src/report/report.cpp
+++ b/src/report/report.cpp
@@ -183,13 +183,16 @@ void init_report_output(char *filename_str, int iterations)
void finish_report_output(void)
{
- fprintf(stderr, _("PowerTOP outputing using base filename %s\n"), reportout.filename);
if (reporttype == REPORT_OFF)
return;
report.finish_report();
- fputs(report.get_result(), reportout.report_file);
- fdatasync(fileno(reportout.report_file));
- fclose(reportout.report_file);
+ if (reportout.report_file)
+ {
+ fprintf(stderr, _("PowerTOP outputing using base filename %s\n"), reportout.filename);
+ fputs(report.get_result(), reportout.report_file);
+ fdatasync(fileno(reportout.report_file));
+ fclose(reportout.report_file);
+ }
report.clear_result();
}
--
1.7.11.7
9 years, 7 months
Multiple Batteries
by Justin Brown
Hello,
I'm using Powertop 2.1, and I've noticed a somewhat minor bug. (I couldn't
find a public bug tracker, but would be more than happy to move this
discussion to one if someone could send me a URL.)
I have two batteries in my laptop, but Powertop does not recognize both
when calculating battery life remaining. For example Gnome-Shell reports
that my batteries are at 66% and 100% (85% combined) giving me 10 hours and
11 minutes of estimated time remaining. On the other hand, Powertop reports
just 3 hours 17 minutes of time. Both programs are reporting the proper
discharge rate. It just seems like Powertop is only using my smaller
battery (the currently active one).
I'm not sure if this issue has been reported, or if the developers even
have equipment with which to test. I'm more than willing to provide any
sort of debugging output or testing as needed. I could also probably create
a patch, but that's likely to take a lot longer for me to get setup with
development on this project.
It may be as simple as iterating over a directory in /sys/ or /proc to
gather stats on multiple batteries. An experienced dev might be able to fix
it quickly.
Cheers,
Justin
9 years, 7 months
Anybody run powerTop2.0 on omap4 (pandaboard)?
by Jaeyeon Kihm
Hi all,
I tried to run powerTop to monitor power consumption on an omap4 board
(pandaboard) and actually it's running on. However, I couldn't get C-states
that I expected. Due to the omap4 characteristics, it's supposed to have C0
to C6 states but my powerTop has only C1 to C3.
Based on this manual (
http://processors.wiki.ti.com/index.php/Running_PowerTOP_on_OMAP35x_platform)
additional patch would be required to update c-states for omap architecture
but I couldn't find the files (powertop.c, powertop.h display.c) as
described in this manual.
Does anybody run powerTop on omap4 (or pandaboard) environment? Could you
share how did you set up powerTop on omap4 architecture?
Thanks,
Jaeyeon
9 years, 7 months
[Announcement] Release of PowerTOP v2.2
by Chris Ferron
PowerTOP v2.2 Release
We are pleased to announce the release of PowerTOP v2.2, which concludes
a minor release.
About PowerTOP
PowerTOP is a Linux tool to diagnose issues with power consumption and
power management. In addition to being a diagnostic tool, PowerTOP also
has an interactive mode you can use to experiment with various power
management settings, for cases where the Linux distribution has not
enabled those settings.
PowerTOP reports which components in the system are most likely to blame
for higher-than-needed power consumption, ranging from software
applications to active components in the system. Detailed screens are
available for CPU C and P states, device activity, and software activity.
For many years, PowerTOP has been used heavily by Intel, Linux
distributors, and various parts of the open source community. We're
hoping that our users find the second generation even more useful for
their needs.
Highlights
Continued Transifex inclusions
Added localization of the UI, with 15 languages in progress and active.
Added UI navigation enhancement for scrolling and tab navigation.
"Arrow Keys" now scroll the tab windows
"Page up/down" scroll tab windows up and down
"TAB" cycles the next window tab
"SHIFT+TAB" cycles the previous window tab
"ENTER" toggles tunables
"SPACE BAR" toggles tunables
"r KEY" refresh results and resets view of tab window
Added new report generator facility.
Added tuning suggestions for updated libata driver.
Added fixes for autoconf to better support distributions.
Added additional ARM support work.
Bug fixes and clean up
Project Details
URL: https://01.org/powertop
Download: https://01.org/powertop/downloads/2012/PowerTOP-v2.2
Mailing list:
Discussions about PowerTOP occur on the PowerTOP(a)lists.01.org mailing list.
Subscribe to the list at https://lists.01.org/mailman/listinfo/powertop
Archives are found at http://lists.01.org/pipermail/powertop
The development PowerTOP git repositories are hosted at GitHub.
URL: https://github.com/fenrus75/powertop
HTTP: https://github.com/fenrus75/powertop.git
GIT-readonly: git://github.com/fenrus75/powertop.git
Note: We will not use any of GitHub's integrate, merge, or tracking
functions, so please continue to use the provided lists.
For localization support and contributions, we are using Transifex.
Transifex URL: https://www.transifex.com/projects/p/PowerTOP/
Our thanks
For this release, we would like to give a special thanks to the
following contributors, and all contributors to PowerTOP. In no
particular order:
Mikko Rapeli, Colin Ian King, Namhyung Kim, Igor Zhbanov, Sergey
Senozhatsky, Rajagopal Venkat, Joerg Mayer, Chris E Ferron
9 years, 7 months
[PATCH] cpu: Fix leftovers from the P state cpu frequency calculation
by Namhyung Kim
The commit 15b8bfb ("Ignore non-P-state-enabled CPUs when calculating
frequency") and 29f42b5 ("fixed issues with p-state reported CPU
frequencies") fixed frequency calculation for cpu packages but missed
it for cpu cores. Add it.
This fixes wrong frequency report on my quad-core box: 2072.5% -> 100.0%
Cc: Ivan Shapovalov <intelfx100(a)gmail.com>
Signed-off-by: Namhyung Kim <namhyung(a)gmail.com>
---
src/cpu/cpu_core.cpp | 3 +--
src/cpu/intel_cpus.cpp | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/cpu/cpu_core.cpp b/src/cpu/cpu_core.cpp
index b0dd4da..2caa58d 100644
--- a/src/cpu/cpu_core.cpp
+++ b/src/cpu/cpu_core.cpp
@@ -131,10 +131,9 @@ void cpu_core::calculate_freq(uint64_t time)
bool is_idle = true;
unsigned int i;
-
/* calculate the maximum frequency of all children */
for (i = 0; i < children.size(); i++)
- if (children[i]) {
+ if (children[i] && children[i]->has_pstates()) {
uint64_t f = 0;
if (!children[i]->idle) {
f = children[i]->current_frequency;
diff --git a/src/cpu/intel_cpus.cpp b/src/cpu/intel_cpus.cpp
index f7b86bc..19ad85c 100644
--- a/src/cpu/intel_cpus.cpp
+++ b/src/cpu/intel_cpus.cpp
@@ -240,7 +240,7 @@ void nhm_core::calculate_freq(uint64_t time)
/* calculate the maximum frequency of all children */
for (i = 0; i < children.size(); i++)
- if (children[i]) {
+ if (children[i] && children[i]->has_pstates()) {
uint64_t f = 0;
if (!children[i]->idle) {
f = children[i]->current_frequency;
--
1.7.9.2
9 years, 7 months
[RFC] [PATCH 00/11] Code deduplication and a single i965 P-states accounting bugfix in cpu/*
by Ivan Shapovalov
This is a series of refactor (well, mainly deduplication) of cpu/* code followed with a
single bugfix patch.
The bugfix itself may be applied even without applying refactoring, but then
the same change shall be applied to all copies of calculate_freq().
So the whole purpose of the series is to
1) mercilessly purge those method overrides which are identical to the methods in base
classes, and
2) prefer defining a helper function and overriding it rather than copy-pasting
the whole big function whose behavior needs to be altered and changing one-two lines in it.
Ivan Shapovalov (11):
Fix includes: do not include intel_cpus.h inside cpu.h
Deduplication: move is_turbo() function to lib
Deduplication: move all instances of account_freq() to
abstract_cpu::account_freq()
Deduplication: remove nhm_cpu::account_freq() almost identical to
abstract_cpu::account_freq()
Deduplication: remove
nhm_{cpu,core,package}::change_effective_frequency() identical to
cpu_{linux,core,package}::change_effective_frequency()
Deduplication: merge
cpu_{core,linux,package}::change_effective_frequency() into
abstract_cpu::change_effective_frequency()
Deduplication: remove {cpu,nhm}_core::calculate_freq() identical to
abstract_cpu::calculate_freq()
Deduplication: remove nhm_package::calculate_freq() identical to
cpu_package::calculate_freq()
Deduplication: properly merge cpu_package::calculate_freq() into
abstract_cpu::calculate_freq()
Deduplication: merge go_idle()/go_unidle()/change_freq() overrides
into abstract_cpu() class
Ignore non-P-state-enabled CPUs when calculating frequency.
src/cpu/abstract_cpu.cpp | 69 ++++++++++--
src/cpu/cpu.cpp | 1 +
src/cpu/cpu.h | 29 ++----
src/cpu/cpu_core.cpp | 97 -----------------
src/cpu/cpu_linux.cpp | 98 ------------------
src/cpu/cpu_package.cpp | 102 ++----------------
src/cpu/intel_cpus.cpp | 265 +----------------------------------------------
src/cpu/intel_cpus.h | 23 +---
src/cpu/intel_gpu.cpp | 2 +-
src/lib.cpp | 9 ++
src/lib.h | 1 +
11 files changed, 94 insertions(+), 602 deletions(-)
--
1.8.0
9 years, 7 months
