* Brown, Len wrote:
> > This driver only knows how to handle counters, though. I'm not sure
> > whether all of the MSRs that turbostat needs are counters.
>
> turbostat --debug
> dumps a lot of configuration MSRs that are not counters.
>
> "--debug" is not an obscure option, it is the only way
On Thu, Jul 2, 2015 at 12:22 PM, H. Peter Anvin wrote:
> On 07/01/2015 09:38 AM, Brown, Len wrote:
>>
>> BTW. I've had a discussion w/ LLNL about their needs,
>> both for security and performance. For security, as concluded
>> by this thread, a white list is the only way to go.
>> I'm thinking a
On 07/01/2015 09:38 AM, Brown, Len wrote:
>
> BTW. I've had a discussion w/ LLNL about their needs,
> both for security and performance. For security, as concluded
> by this thread, a white list is the only way to go.
> I'm thinking a bit-vector of allowed MSR offsets...
> For performance, they a
* Andy Lutomirski wrote:
> On Wed, Jul 1, 2015 at 9:38 AM, Brown, Len wrote:
>
> > BTW. I've had a discussion w/ LLNL about their needs, both for security and
> > performance. For security, as concluded by this thread, a white list is
> > the
> > only way to go. I'm thinking a bit-vector of
On Wed, Jul 1, 2015 at 9:38 AM, Brown, Len wrote:
> BTW. I've had a discussion w/ LLNL about their needs,
> both for security and performance. For security, as concluded
> by this thread, a white list is the only way to go.
> I'm thinking a bit-vector of allowed MSR offsets...
> For performance,
> This driver only knows how to handle counters, though. I'm not sure
> whether all of the MSRs that turbostat needs are counters.
turbostat --debug
dumps a lot of configuration MSRs that are not counters.
"--debug" is not an obscure option, it is the only way that
the turbostat is used by advan
On 06/30/2015 08:44 AM, Peter Zijlstra wrote:
> On Tue, Jun 30, 2015 at 08:20:55AM -0400, Prarit Bhargava wrote:
>> it seems like visiting changes on each of these packages (and the other
>> packages that I'm sure I've missed) will be moderately difficult.
>>
>> Thoughts?
>
> Start by changing t
* Peter Zijlstra wrote:
> On Tue, Jun 30, 2015 at 08:20:55AM -0400, Prarit Bhargava wrote:
> > it seems like visiting changes on each of these packages (and the other
> > packages that I'm sure I've missed) will be moderately difficult.
> >
> > Thoughts?
>
> Start by changing the ones users wa
On Tue, Jun 30, 2015 at 08:20:55AM -0400, Prarit Bhargava wrote:
> it seems like visiting changes on each of these packages (and the other
> packages that I'm sure I've missed) will be moderately difficult.
>
> Thoughts?
Start by changing the ones users want to run most and leave the rest
requiri
The MSR exposure seems to be okay with the following statements:
- complete read of /dev/cpu/X/msr is bad, whitelist instead
- needs to be dependent on either CPU version or reading MSRs for support.
IIRC the Intel documentaton on the MSRs indicated that there are ways to
check to see if a pa
On 06/28/2015 07:34 AM, Prarit Bhargava wrote:
>>
>> Seriously, though, it would be straightforward to make it handle a
>> more general list, complete with non-architectural stuff (such as the
>> upcoming PPERF in Skylake).
>
> Is it easier to blacklist MSRs we don't want generally exposed, or onl
On Sun, 28 Jun, at 12:10:49PM, Henrique de Moraes Holschuh wrote:
> On Sun, 28 Jun 2015, Prarit Bhargava wrote:
> > Is it easier to blacklist MSRs we don't want generally exposed, or only
> > expose
> > the ones that we think are safe? That's sort of a devil's advocate sort of
> > question ;) and
* Henrique de Moraes Holschuh wrote:
> On Sun, 28 Jun 2015, Prarit Bhargava wrote:
>
> > Is it easier to blacklist MSRs we don't want generally exposed, or only
> > expose
> > the ones that we think are safe? That's sort of a devil's advocate sort of
> > question ;) and I'm wondering what th
On Fri, 26 Jun 2015, Prarit Bhargava wrote:
> > The proper way to do this is to write a driver to only expose the MSRs
> > that the user tools need, and nothing else.
>
> Will do -- At least I got everyone's attention with this :).
IMHO we need both a new driver that exposes semanthic functionali
On Sun, 28 Jun 2015, Prarit Bhargava wrote:
> Is it easier to blacklist MSRs we don't want generally exposed, or only expose
> the ones that we think are safe? That's sort of a devil's advocate sort of
> question ;) and I'm wondering what the shorter list is.
The only way to make MSR access safe
On 06/27/2015 11:52 AM, Andy Lutomirski wrote:
> On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>>
>> * Ingo Molnar wrote:
>>
>>> So what's wrong with exposing them as a simplified PMU driver?
>>>
>>> That way we only expose the ones we want to - plus tooling can use all the
>>> rich
>>>
On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> So what's wrong with exposing them as a simplified PMU driver?
>>
>> That way we only expose the ones we want to - plus tooling can use all the
>> rich
>> perf features that can be used around this. (sampling, coun
* Ingo Molnar wrote:
> So what's wrong with exposing them as a simplified PMU driver?
>
> That way we only expose the ones we want to - plus tooling can use all the
> rich
> perf features that can be used around this. (sampling, counting, call chains,
> etc.)
See below code from Andy that e
* Prarit Bhargava wrote:
> Customers write system monitoring software for single systems as well as
> clusters. In load-balancing software it is useful to know how "busy" a
> core is. Unfortunately the only way to get this data is to run as root,
> or use setcap to allow userspace access for p
On 06/26/2015 03:23 PM, Brian Gerst wrote:
> On Fri, Jun 26, 2015 at 1:52 PM, Prarit Bhargava wrote:
>> Customers write system monitoring software for single systems as well as
>> clusters. In load-balancing software it is useful to know how "busy" a
>> core is. Unfortunately the only way to g
On Fri, Jun 26, 2015 at 1:52 PM, Prarit Bhargava wrote:
> Customers write system monitoring software for single systems as well as
> clusters. In load-balancing software it is useful to know how "busy" a
> core is. Unfortunately the only way to get this data is to run as root,
> or use setcap to
On 06/26/2015 10:52 AM, Prarit Bhargava wrote:
>
> This patch allows read access to the msr dev files which should be okay.
> No damage can be done by reading the MSR values and it allows non-root
> users to run system monitoring software.
>
I don't believe that is true.
-hpa
--
To un
Customers write system monitoring software for single systems as well as
clusters. In load-balancing software it is useful to know how "busy" a
core is. Unfortunately the only way to get this data is to run as root,
or use setcap to allow userspace access for particular programs. Both of
these o
23 matches
Mail list logo
