This is a follow up from the thread: https://software.intel.com/en-us/forums/topic/508577
I was able to get an account on a machine at my work that has newer Intel Processors so that I can run my PCM tests. The computer has some Xeon E7-4870 processors inside. I am unsure of the OS beyond it being Linux, though if I had to guess, I would say SUSE.
I got everything compiled correctly, both the PCM and my own code. When I ran my first test, I got the following error message:
> > Can not access CPUs Model Specific Registers (MSRs).
> > Try to execute 'modprobe msr' as root user and then
> > you also must have read and write permissions for /dev/cpu/*/msr devices
> > (the 'chown' command can help). make: *** [runEpetra] Error 1
I am discussing this with the administrator at the moment. For obvious reasons, he is quite concerned about giving root/read-write access to an unknown program so that some guy can run some tests. I gave him links to the PCM website so he can read up, but I also told him I would inquire about ways to run the PCM effectively without root access.
So, is there a way to run my tests without root access without causing the above problem?
One option is to place a copy of the pcm executable in a directory that only your user account can read&execute and then mark the executable as "setuid root". I have not done this with pcm, but I do it with other performance tools every day.
I don't know how carefully pcm sanitizes its inputs -- I would imagine that there is a fair chance that you could accidentally (or deliberately) mess up the system using this tool, but by limiting access to the binary to your account the administrator will know exactly who to blame. :-)
An alternative that should be slightly safer is to create a new group (e.g., "msrgroup") to control access to the /dev/cpu/*/msr device driver interfaces. You again create a private copy of pcm that is "setgid msrgroup", then change the group ownership of the /dev/cpu/*/msr device driver interfaces to "msrgroup" and add group read+write permissions to the files. This may not be enough for full functionality of PCM (for example, it will not provide access to PCI configuration space), but since it is a more limited approach it should be safer and may be worth a try.
Dr. McCalpin mentions various ways to try and reduce the rights required by PCM.
But you need access (somehow) to the /dev/cpu/*/msr device which only root can grant.
If your administrator is just worried about PCM as opposed to allowing anyone/anytime access to /dev/cpu/*/msr then you can try using the Linux 'perf' utility. Perf lets you program/read the hardware counters (and a lot more). If the admin doesn't allow perf to run then I doubt PCM will be allowed. Remember that reading/writing MSRs give you access to potentially crashing the machine and/or gathering info about processes besides your own processes... so an admin is right to be concerned. The PCM code has been pretty thoroughly tested so wouldn't worry about it crashing a system but if your admin's job depends on system uptime I doubt my words will much impact.
You might also look at the sysstat utilities (http://sebastien.godard.pagesperso-orange.fr/) such as sar, iostat, pidstat, etc. The may already be installed on the system and perhaps will do what you need.
It depends on what you are trying to accomplish...
If you provide some other executable as argument to PCM, PCM will execute it and report the counters. This might turn into a problem. One could comment out this system call from the sources to remove this feature.
Other alternatives are to run pcm-sensor as a daemon and let you connect to it. However, you need be aware that the resolution is only 1s in this case.