Honor proposed Intel Hardware performance counter usage policy

srikanthputcha / likwid

Automatically exported from code.google.com/p/likwid

GNU General Public License v3.0

0 stars 0 forks source link

Honor proposed Intel Hardware performance counter usage policy #85

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago

Problem:

Likwid overwrites anything in the counter registers without asking. Intel 
proposed to allow using multiple tools without interference.

Solution:

Honor the solution of the Intel Whitepaper. Provide a overwrite mode.
Make init and setup of counters specific for the thread group and performance 
group. (Only overwrite register which are needed)

Original issue reported on code.google.com by jan.trei...@gmail.com on 3 Dec 2012 at 9:36

GoogleCodeExporter commented 8 years ago

Original comment by jan.trei...@gmail.com on 8 May 2013 at 8:24

Added labels: Release-3.1

GoogleCodeExporter commented 8 years ago

Intel's Performance Monitoring Unit Sharing Guide is attached. 

http://software.intel.com/file/30388

Original comment by n...@verse.com on 5 Nov 2013 at 2:08

Attachments:

[Performance Monitoring Unit Sharing Guide.pdf](https://storage.googleapis.com/google-code-attachments/likwid/issue-85/comment-2/Performance Monitoring Unit Sharing Guide.pdf)

GoogleCodeExporter commented 8 years ago

Delayed to next release

Original comment by jan.trei...@gmail.com on 22 Jan 2014 at 1:37

Removed labels: Release-3.1

GoogleCodeExporter commented 8 years ago

The paper is outdated. Further counters as Uncore (PCI based) and RAPL are not 
addressed.

Therefore this issue is delayed.

Original comment by jan.trei...@gmail.com on 8 May 2014 at 11:06

Added labels: Priority-Low
Removed labels: Priority-Medium

GoogleCodeExporter commented 8 years ago

I really would like to see some method that checks whether the counters are 
already in use - Intel PCM reports within its init phase if the counters are 
not zeroed and ask to enforce a clearing.
But there is also a conflict with tools like PAPI that rely on the Linux kernel 
perf_event interface: these tools do not set the MSRs directly and do not clean 
up at the end. So monitoring a node as root using likwid (or Intel PCM) might 
always fail if an application used the perf_event interface.

Original comment by bockelm...@org.dkrz.de on 4 Aug 2014 at 9:09

GoogleCodeExporter commented 8 years ago

The current trunk version checks the counter at the beginning. It skipps 
counters where the control register is not empty. In general we wanted to avoid 
additional register reads at the beginning as we have seen long access times 
for the MSRs in particular situations. But these checks are needed so that we 
can use common control files for e.g. SandyBridge and SandyBridge EP.
In the end, LIKWID zeros the control registers but leaves the counter registers 
untouched.

Original comment by Thomas.R...@googlemail.com on 28 Aug 2014 at 4:32

GoogleCodeExporter commented 8 years ago

This is not so easy to realize. Currently Likwid checks if registers are 
readable and writable but does not fail when config registers are already in 
use. There is no flag like "--force".

We think about it in Likwid 4.1

Original comment by Thomas.R...@googlemail.com on 5 May 2015 at 1:53

Added labels: Release-4.1

GoogleCodeExporter commented 8 years ago

I copied the issue to the GitHub issue tracker. Since Google Code is closed in 
the future, we move to GitHub.
https://github.com/rrze-likwid/likwid/issues/2

Original comment by Thomas.R...@googlemail.com on 8 Jun 2015 at 12:22