Giter Site home page Giter Site logo

energymon / energymon Goto Github PK

View Code? Open in Web Editor NEW
34.0 6.0 17.0 1.19 MB

A portable interface for energy monitoring utilities

License: Apache License 2.0

C 79.10% CMake 17.73% Roff 3.17%
energy energy-monitoring-utilities msr rapl odroid wattsup interface portable odroid-smart-power c seec feedback-mechanism cray-pm zcu102 raplcap ibmpowernv powercap jetson intel-power-gadget

energymon's Introduction

Energy Monitoring Interface

EnergyMon provides a general C interface for energy monitoring utilities.

If using this project for other scientific works or publications, please reference:

  • Connor Imes, Lars Bergstrom, and Henry Hoffmann. "A Portable Interface for Runtime Energy Monitoring". In: FSE. 2016. DOI: https://doi.org/10.1145/2950290.2983956

    [BibTex]
    @inproceedings{imes2016energymon,
      author = {Imes, Connor and Bergstrom, Lars and Hoffmann, Henry},
      title = {A Portable Interface for Runtime Energy Monitoring},
      year = {2016},
      isbn = {9781450342186},
      publisher = {Association for Computing Machinery},
      address = {New York, NY, USA},
      url = {https://doi.org/10.1145/2950290.2983956},
      doi = {10.1145/2950290.2983956},
      booktitle = {Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering},
      pages = {968–974},
      numpages = {7},
      keywords = {portable energy measurement},
      location = {Seattle, WA, USA},
      series = {FSE 2016}
    }
  • You may also find an extended analysis in the Tech Report.

    [BibTex]
    @techreport{imes2016energymon-tr,
      author = {Imes, Connor and Bergstrom, Lars and Hoffmann, Henry},
      title = {A Portable Interface for Runtime Energy Monitoring: Extended Analysis},
      institution = {University of Chicago, Department of Computer Science},
      number = {TR-2016-08},
      year = {2016},
      month = sep,
      address = {Chicago, IL, USA}
    }

Applications using some libraries may need to be executed using elevated privileges.

The following instructions are for Linux systems. If you are using a different platform, change the commands accordingly.

Current EnergyMon implementation options are:

  • dummy [default]: Mock implementation
  • cray-pm: Cray XC30 and XC40 systems (e.g., NERSC Cori) via Linux sysfs files
  • ibmpowernv: IBM PowerNV systems (e.g., OLCF Summit) via Linux sysfs energy sensor files
  • ibmpowernv-power: IBM PowerNV systems (e.g., OLCF Summit) via Linux sysfs power sensor files
  • ipg: Intel RAPL via Intel Power Gadget
  • jetson: NVIDIA Jetson systems with INA3221 power sensors via Linux sysfs files
  • msr: Intel RAPL via Linux Model-Specific Register device files (supports most non-Atom CPUs)
  • odroid: Hardkernel ODROID XU+E and XU3 systems (with INA-231 power sensors) via Linux sysfs files
  • odroid-ioctl: Hardkernel ODROID XU+E and XU3 systems (with INA-231 power sensors) via ioctl on Linux device files
  • osp: Hardkernel ODROID Smart Power meters (coarse-grained energy counter) via HIDAPI
  • osp-polling: Hardkernel ODROID Smart Power meters (finer-grained power sensor) via HIDAPI
  • osp3: ODROID Smart Power 3 meters via Linux and macOS device files
  • rapl: Intel RAPL via Linux powercap sysfs files
  • raplcap-msr: Intel RAPL via libraplcap-msr (more capable than msr implementation above)
  • shmem: Shared memory client via an EnergyMon shared memory provider
  • wattsup: Watts Up Pro meter via Linux and macOS device files
  • wattsup-libusb: Watts Up Pro meter via libusb
  • wattsup-libftdi: Watts Up Pro meter via libftdi
  • zcu102: Xilinx Zynq UltraScale+ ZCU102 systems (with INA-226 power sensors) via Linux sysfs files

See the README files in subdirectories for implementation specifics, including dependencies.

Building

This project uses CMake.

By default, all libraries will be built, with dummy as the energymon-default implementation:

mkdir _build
cd _build
cmake ..
make

To use a different default implementation, e.g., the RAPL energy monitor, specify ENERGYMON_BUILD_DEFAULT with cmake:

cmake -DENERGYMON_BUILD_DEFAULT=rapl ..

Set ENERGYMON_BUILD_DEFAULT=NONE to disable building a default implementation. Its default value is dummy.

To build only a single library, e.g., the RAPL energy monitor, specify ENERGYMON_BUILD_LIB with cmake:

cmake -DENERGYMON_BUILD_LIB=rapl ..

Set ENERGYMON_BUILD_LIB=NONE to only build the default implementation (if set). Set back to its default value of ALL to build all libraries.

To build shared objects / dynamically linked libraries instead of static libraries, set BUILD_SHARED_LIBS with cmake:

cmake .. -DBUILD_SHARED_LIBS=ON

For an optimized build, set CMAKE_BUILD_TYPE when with cmake, e.g., one of:

cmake .. -DCMAKE_BUILD_TYPE=Release
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo

Of course, you can specify multiple options, e.g.:

cmake .. -DENERGYMON_BUILD_LIB=NONE -DENERGYMON_BUILD_DEFAULT=rapl -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release

Other Build Options

Boolean options:

  • ENERGYMON_BUILD_SHMEM_PROVIDERS - enable/disable building shared memory providers (True by default)
  • ENERGYMON_BUILD_UTILITIES - enable/disable building utility applications (True by default)
  • ENERGYMON_BUILD_TESTS - enable/disable building test code (True by default)
  • ENERGYMON_BUILD_EXAMPLES - enable/disable building examples (True by default)

Installing

To install libraries, headers, and binaries, run with proper privileges:

make install

On Linux, the installation usually places libraries in /usr/local/lib, header files in /usr/local/include/energymon, and binary files in /usr/local/bin.

Uninstalling

To remove files installed to the system, run with proper privileges:

make uninstall

Linking

Library names have the format energymon-foo, where foo is a short name from the bulleted list above. For example, the dummy library is named energymon-dummy. The following instructions use the default library for simplicity and portability, but substitute names as needed.

CMake

Projects that use CMake can find the EnergyMon package and link against imported targets, which automatically applies properties like header search paths and transitive dependencies:

find_package(EnergyMon REQUIRED)

add_executable(hello_world hello_world.c)
target_link_libraries(hello_world PRIVATE EnergyMon::energymon-default)

pkg-config

A more general approach for linking with an EnergyMon library is to use pkg-config:

cc $(pkg-config energymon-default --cflags) hello_world.c \
   $(pkg-config energymon-default --libs --static) -o hello_world

or in a Makefile:

CFLAGS += $(shell pkg-config --cflags energymon-default)
LDFLAGS += $(shell pkg-config --libs --static energymon-default)

hello_world: hello_world.c
	$(CC) $(CFLAGS) hello_world.c -o $@ $(LDFLAGS)

If shared object libraries are installed, don't include the --static option.

Projects that use CMake >= 3.6 can alternatively use a pkg-config IMPORTED_TARGET, rather than the direct CMake imports documented above:

find_package(PkgConfig REQUIRED)
pkg_check_modules(EnergyMonDefault REQUIRED IMPORTED_TARGET energymon-default)

add_executable(hello_world hello_world.c)
target_link_libraries(hello_world PRIVATE PkgConfig::EnergyMonDefault)

Usage

To use an EnergyMon implementation, you must first populate the struct by calling the getter function, then initialize it. Don't forget to cleanup the instance once you're finished with it. See energymon.h and energymon-default.h for more detailed function descriptions.

  energymon em;
  uint64_t start_uj, end_uj;

  // get the energymon instance and initialize
  energymon_get_default(&em);
  em.finit(&em);

  // profile application function
  start_uj = em.fread(&em);
  do_work();
  end_uj = em.fread(&em);
  printf("Total energy for do_work() in microjoules: %"PRIu64"\n", end_uj - start_uj);

  // destroy the instance
  em.ffinish(&em);

Tools

This project includes a handful of applications.

Utilities

All of the following are linked with energymon-default:

  • energymon-cmd-profile: Prints out time, energy, and power statistics for the execution of a given shell command.
  • energymon-power-poller: Prints average power values at the requested interval for the previous interval period.
  • energymon-file-provider: Writes energy data to a file (overwrites previous values).
  • energymon-idle-power: Prints the average power over the given interval (meant to run in isolation and measure idle power consumption).
  • energymon-info: Prints information about the implementation.
  • energymon-overhead: Prints the latency overhead in nanoseconds of the functions finit, fread, and ffinish.

Implementation-specific versions of these utilities are also provided.

Shared Memory Providers

Shared memory providers allow exposing energy data to one or more unprivileged applications for sources that require elevated privileges and/or exclusive access. The providers may need to run with elevated privileges, but other applications can attach to their shared memory and read energy data using the shmem EnergyMon implementation.

  • energymon-osp-polling-shmem-provider
  • energymon-wattsup-shmem-provider
  • energymon-wattsup-libftdi-provider
  • energymon-wattsup-libusb-provider

Project Source

Find this and related project sources at the energymon organization on GitHub.
This project originates at: https://github.com/energymon/energymon

Bug reports and pull requests for new implementations, bug fixes, and enhancements are welcome.

energymon's People

Contributors

cimes-isi avatar connorimes avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

energymon's Issues

Bad Makefile produced when using both -DCMAKE_TOOLCHAIN_FILE and -DDEFAULT

When using both a toolchain file and specifying a default implementation, build scripts are not produced properly.

Running make produces:

Linking C executable bin/energymon
/local/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lenergymon-default
CMakeFiles/energymon.dir/src/app/energymon.c.o:energymon.c:function main: error: undefined reference to 'energymon_get_default'
collect2: error: ld returned 1 exit status
CMakeFiles/energymon.dir/build.make:85: recipe for target 'bin/energymon' failed
make[2]: *** [bin/energymon] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/energymon.dir/all' failed
make[1]: *** [CMakeFiles/energymon.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Trying to specify make energymon-default-static produces:

make: *** No rule to make target 'energymon-default-static'.  Stop.

Only the dummy implementation appears to be available.

ipg: PG_Shutdown causes errors in readers getting samples from PMU

This issue is for documentation purposes, since it's not really a bug in energymon-ipg.

The ipg implementation experiences issues when multiple instances---or other software tools, including Intel Power Gadget itself---share the PowerGadgetLib backend. Calling the shutdown method in any one instance causes errors on other readers:

ERROR: EnergyDriver_executeCommands [via readSample] returned 0xe00002bc

Example: Start Intel Power Gadget, run software using PowerGadgetLib w/out usePMU=false, stop this software (PG_Shutdown), then IPG starts failing to collect data.

I asked about the issue on Intel's forums some time ago, but didn't receive a reply [1].

[1] https://community.intel.com/t5/Software-Tuning-Performance/Power-Gadget-PG-Shutdown-when-UsePMU-false-still-affects-SW/m-p/1341318

OSP overflow is not 1000 Wh

The existing value of 1000 was assumed by the number of available digits on the device display, but in fact it will go higher and simply not display the full "Wh" on the display once 1000 Wh is reached. If the ODROID Smart Power is plugged into an ODROID device and is performing computation, it can still take days of continuous execution to reach the 1000 Wh threshold. Perhaps the overflow is 10k Wh? 100k Wh? Higher? Leaving this issue open until we can identify the actual overflow point.

Fortunately the implementation doesn't incorrectly detect an overflow when 1000 Wh is reached. A problem will only appear when the actual overflow point is reached, at which point the read function will return an value that is too small.

Bug in elapsed time calculation

There is a bug in either the microsecond versions of the ptime routines or in the way that they are used by the sensor-polling threads in the odroid, odroid-ioctl, osp, wattsup and zcu102 implementations. I can't tell which is incorrect because the function descriptions in common/ptime/ptime.h are a bit vague. Specifically, they don't say what the units are for the since argument in any of the routines. Right now, both the _ns and _us versions of the routines treat since as if it is in nanoseconds. However, the polling routines capture an initial time in microseconds and then pass that to energymon_gettime_elapsed_us which passes it to ptime_gettime_elapsed_us. Thus the first elapsed time calculation is incorrect and therefore the first energy calculation is incorrect. The elapsed time routines update since with a time in nanoseconds so it works correctly for subsequent invocations and the difference between two energy readings will be correct but the total is not.

You can see this problem by running the interval_test. Here's the output on a zcu102 compiled with ENERGYMON_DEBUG=1:

jasonm@ubuntu:~/energymon_github/_build64$ test/interval-test 100000
Initializing reading from ZCU102 INA226 Power Sensors
zcu102_poll_sensors: Read total power: 3025000 uW (3.025000 W)
zcu102_poll_sensors: Calculated energy: 3.025000 W * 6200404583720 us = 18756223865753 uJ
zcu102_poll_sensors: Read total power: 3025000 uW (3.025000 W)
zcu102_poll_sensors: Calculated energy: 3.025000 W * 7159 us = 21655 uJ
zcu102_poll_sensors: Read total power: 3025000 uW (3.025000 W)
zcu102_poll_sensors: Calculated energy: 3.025000 W * 35018 us = 105929 uJ
zcu102_poll_sensors: Read total power: 3000000 uW (3.000000 W)
zcu102_poll_sensors: Calculated energy: 3.000000 W * 7188 us = 21564 uJ
Start energy: 0 uJ   End energy: 18756224014901 uJ
Total energy: 18756224014901 uJ
Average power: 187562240.149010 W
Finished reading from ZCU102 INA226 Power Sensors

I'm happy to fix this if I can get clarification on whether the since argument for energymon_gettime_elapsed_us and ptime_gettime_elapsed_us is supposed to be in microseconds or nanoseconds.

Windows MinGW build fails with '-pedantic-errors' flag due to inttypes.h inlining unused 'llabs' function

I've removed the -pedantic-errors compile flag so that we only get a warning now. Maybe somebody would care to figure out if this is a problem that can be solved on our end.

In file included from C:\projects\energymon\dummy\energymon-dummy.c:9:0:
c:\mingw\include\inttypes.h:268:11: warning: inline function 'llabs' declared but never defined
 long long llabs (long long);
           ^
c:\mingw\include\inttypes.h:268:11: warning: inline function 'llabs' declared but never defined

MinGW: energymon-shmem fails to compile

Need to see if this is just an include problem or if IPC won't work like this in Windows. If the latter, we shouldn't attempt to compile this implementation for Windows.

C:\development\git\energymon\shmem\energymon-shmem.c:11:21: fatal error: sys/ipc
.h: No such file or directory
 #include 
                     ^
compilation terminated.

rapl: implementation assumes package as top-level zone

It turns out the newer psys type can also be a top-level zone. This is somewhat strange because there is now heterogeneity in the top-level zone types. In any case, the zone name needs to be checked before including its readings.

microjoules value: 0 from API

My code(profile_stress.c):

#include <stdio.h>
#include <stdlib.h>
#include "energymon.h"

int main(void)
{
	energymon em;
	uint64_t start_uj, end_uj;

	

	energymon_get_default(&em);
	em.finit(&em);

	// profile application function
	start_uj = em.fread(&em);
        system("stress -c 1 -t 10");
	end_uj = em.fread(&em);

	printf("Total energy for stress -c 1 -t 10 in microjoules: %"PRIu64"\n", end_uj - start_uj);

	// destroy the instance
	em.ffinish(&em);

	return 0;
}

The Makefile:

CFLAGS += $(shell pkg-config --cflags energymon-default)
LDFLAGS += $(shell pkg-config --libs --static energymon-default)

profile_stress: profile_stress.c
	$(CC) $(CFLAGS) profile_stress.c -o $@ $(LDFLAGS)

run step:

make
sudo ./profile_stress

stress: info: [1491] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
stress: info: [1491] successful run completed in 10s
Total energy for stress -c 1 -t 10 in microjoules: 0

but if run via energy-rapl-cmd-profile:
sudo energymon-rapl-cmd-profile stress -c 1 -t 10
Executing: stress -c 1 -t 10
stress: info: [1555] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
stress: info: [1555] successful run completed in 10s
Time (ns): 10004833886
Energy (uJ): 640470528
Power (W): 64.016108

My system:
Ubutnu 22.04
CPU: Intel W7-2495X
Linux u22 6.4.11-060411-generic #202308161732 SMP PREEMPT_DYNAMIC Wed Aug 16 17:41:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

How can I fix this problem?

wattsup-libftdi: ftdi_usb_purge_buffers is deprecated

On Travis OSX builds, we're now getting a deprecation warning:

[ 73%] Building C object wattsup/libftdi/CMakeFiles/energymon-wattsup-libftdi.dir/__/energymon-wattsup.c.o
[ 73%] Building C object wattsup/libftdi/CMakeFiles/energymon-wattsup-libftdi.dir/wattsup-driver-libftdi.c.o
/Users/travis/build/connorimes/energymon/wattsup/libftdi/wattsup-driver-libftdi.c:80:7: warning: 'ftdi_usb_purge_buffers' is deprecated [-Wdeprecated-declarations]
  if (ftdi_usb_purge_buffers(ctx->ctx)) {
      ^
/usr/local/Cellar/libftdi/1.5_2/include/libftdi1/ftdi.h:566:9: note: 'ftdi_usb_purge_buffers' has been explicitly marked deprecated here
    int DEPRECATED(ftdi_usb_purge_buffers(struct ftdi_context *ftdi));
        ^
/usr/local/Cellar/libftdi/1.5_2/include/libftdi1/ftdi.h:247:42: note: expanded from macro 'DEPRECATED'
#define DEPRECATED(func) __attribute__ ((deprecated)) func
                                         ^
1 warning generated.

This appears to be new since libftdi 1.5 (2020-07-07): https://www.intra2net.com/en/developer/libftdi/

We need to consider backward compatibility before making changes, esp. with versions found in Linux repositories.

Fix direct energy reading in osp

The non-polling version of the ODROID Smart Power implementation doesn't seem to work very well. We probably need to do better resets during initialization.

CMake should fail if bad DEFAULT value specified

If a bad DEFAULT value is specified, CMake should fail with a helpful error message. It should ensure that a valid value is given for the platform being compiled for as well (e.g. it should fail if rapl is specified when running in Windows or on an Apple system). Currently it just doesn't produce the energymon-default and energymon-default-static targets. Running make then fails because it can't link against energymon-default:

Scanning dependencies of target energymon
[  3%] Building C object CMakeFiles/energymon.dir/src/app/energymon.c.o
Linking C executable bin/energymon
/usr/bin/ld: cannot find -lenergymon-default
collect2: error: ld returned 1 exit status
CMakeFiles/energymon.dir/build.make:85: recipe for target 'bin/energymon' failed
make[2]: *** [bin/energymon] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/energymon.dir/all' failed
make[1]: *** [CMakeFiles/energymon.dir/all] Error 2
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

Support building and installing single targets

This would be helpful for wrapper libraries (e.g. the Rust energymon-sys crates).
We should be able to build a single library (or pair of dynamic/static libraries at least) and install only the required files and libs (e.g. to a local install directory by overriding CMAKE_INSTALL_PREFIX when executing cmake).

Some tests have shown that we can achieve this by:

  • setting CMAKE_SKIP_INSTALL_ALL_DEPENDENCY to TRUE in the top level CMakeLists.txt file
# force fPIC on static libs
set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
  • removing the local configure_file in the PKG_CONFIG macro
  • specifying OPTIONAL in install commands in the CMakeLists.txt files, with the exception of the top level header files
  • only conditionally building the osp subproject
  find_package(PkgConfig REQUIRED)
  pkg_search_module(HIDAPIUSB hidapi-libusb)
  if (${HIDAPIUSB_FOUND})
    add_subdirectory(osp)
  else()
    message(STATUS "Did not find hidapi-libusb - skipping OSP implementation")
  endif()
  • Running the following build commands:
make install/local
cd $impl
make
make install

However, we don't necessarily know what $impl actually is since it doesn't match the library name (e.g. rapl instead of energymon-rapl or energymon-rapl-static. It would be preferable to do this all from the top level, but unfortunately this ends up installing extra pkg-config and header files (even though they are OPTIONAL, they exist so are installed).

MinGW: Energymon app compilation failure due to time functionality

Beside the issue in #29, nanosleep and its dependent struct timespec are not recognized.

C:\development\git\energymon\src\app\energymon.c: In function 'main':
C:\development\git\energymon\src\app\energymon.c:45:19: error: storage size of '
ts' isn't known
   struct timespec ts;
                   ^
C:\development\git\energymon\src\app\energymon.c:82:5: warning: ISO C does not s
upport the 'I64' ms_printf length modifier [-Wformat=]
     if (fprintf(fout, "%"PRIu64"\n", energy) < 0) {
     ^
C:\development\git\energymon\src\app\energymon.c:88:5: error: implicit declarati
on of function 'nanosleep' [-Wimplicit-function-declaration]
     nanosleep(&ts, NULL);
     ^
C:\development\git\energymon\src\app\energymon.c:45:19: warning: unused variable
 'ts' [-Wunused-variable]
   struct timespec ts;
                   ^

AppVeyor: Test builds with Windows-compatible dependencies

The appveyor.yml config is currently pretty minimal and only builds implementations that don't have third-party dependencies. Some other energymon implementations should be portable to Windows, like those that depend on libusb-1.0, libftdi, and/or hidapi.

This will probably require downloading and installing these dependencies in the before_build step, and properly configuring the environment so that CMake or pkg-config can correctly locate them. Servo's AppVeyor config may be a good reference [1].

[1] https://github.com/servo/servo/blob/master/appveyor.yml

Build utilities for all library implementations, not just energymon-default

Currently we only build utilities that link against energymon-default. It would be nice to create utilities for all libraries. Perhaps use the implementation names as a suffix, e.g., energymon-info-rapl. This would require a general approach to calling the initial getter function instead of always relying on energymon_get_default, so some kind of transformation from within CMake is probably needed, along with a macro to build the utilities for each library.

Automatically discover MSRs

If the ENERGYMON_MSRS env var is not set, energymon-msr should attempt to discover which MSRs to use. We currently just default to cpu0. Can't just use all MSRs because multiple cores will expose the same MSR.

  • Can we guarantee that a single MSR per processor socket is all that's needed? If so, that makes the task a little easier.
  • Potential options using the shell:
    • lscpu
    • numactl -H (requires numactl to be installed)
  • Can we discover processor architecture through C/POSIX functions?

MinGW: Undeclared signals in energymon app

This isn't the only compile problem for this app, but should have its own issue report given that other systems also may not recognize these signals. Should check for these only on systems that recognize them.

C:\development\git\energymon\src\app\energymon.c: In function 'shandle':
C:\development\git\energymon\src\app\energymon.c:33:10: error: 'SIGQUIT' undecla
red (first use in this function)
     case SIGQUIT:
          ^
C:\development\git\energymon\src\app\energymon.c:33:10: note: each undeclared id
entifier is reported only once for each function it appears in
C:\development\git\energymon\src\app\energymon.c:34:10: error: 'SIGKILL' undecla
red (first use in this function)
     case SIGKILL:
          ^
C:\development\git\energymon\src\app\energymon.c:35:10: error: 'SIGHUP' undeclar
ed (first use in this function)
     case SIGHUP:
          ^

Return uint64_t instead of unsigned long long

For clarity we should return values of known widths for integer values other than success/failure codes or other values that match standard interfaces (like an int for a file descriptor). Types are defined in inttypes.h.

Remove overflow check in rapl impl

It seems to be too aggressive (perhaps because subzones overflow and affect the value of the top level zone without it overflowing on its own). Although energy monitors don't provide thread safety, It poses a potential race condition for readers, which shouldn't be allowed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.