[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1A7043D5F58CCB44A599DFD55ED4C9484686CC03@fmsmsx115.amr.corp.intel.com>
Date: Tue, 28 Apr 2015 22:29:53 +0000
From: "Brown, Len" <len.brown@...el.com>
To: Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: RE: [RFC] x86, perf: Add an aperfmperf driver
> I think that turbostat could do some of its work without being
> root if we had a driver like this.
Note that turbostat can be run as non-root this way:
# setcap cap_sys_rawio=ep ./turbostat
# chmod +r /dev/cpu/*/msr
For the debug case, there are a number of MSRs that turbostat must access,
so would still need permission for that case (which is the only case I use:-)
> Thoughts? Would it make sense at all? Did I wire it up right? This is
> the only PMU driver I've ever written, and it could have any number of
> issues.
APERF/MPERF, as with all per-thread MSRs, must be accessed
from the local processor. I didn't see where this driver
distinguishes the CPU. Also, I assume the intent is to return
a snapshot, rather than sampling, yes?
Note that turbostat binds itself to a remote CPU so that MSR reads
are all local, then it binds to the next CPU etc. In the old days,
we read everything without this binding, and the kernel overhead
of the remote reads was too high, making it difficult to measure
profoundly idle systems.
cheers,
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists