* 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
* Brown, Len len.br...@intel.com 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
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
* 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
* Andy Lutomirski l...@amacapital.net wrote:
On Wed, Jul 1, 2015 at 9:38 AM, Brown, Len len.br...@intel.com 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.
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
On Thu, Jul 2, 2015 at 12:22 PM, H. Peter Anvin h...@zytor.com 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
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
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 advanced
On Wed, Jul 1, 2015 at 9:38 AM, Brown, Len len.br...@intel.com 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...
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
* 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
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
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
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
* Peter Zijlstra pet...@infradead.org 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
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
requiring
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 the ones
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
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 ;)
* 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
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 I'm
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 only expose
* Henrique de Moraes Holschuh h...@hmh.eng.br 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
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
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 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 is
On 06/27/2015 11:52 AM, Andy Lutomirski wrote:
On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar mi...@kernel.org wrote:
* Ingo Molnar mi...@kernel.org 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
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 functionality
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,
* 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
* 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
* Prarit Bhargava pra...@redhat.com 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
* Ingo Molnar mi...@kernel.org 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
On Sat, Jun 27, 2015 at 1:39 AM, Ingo Molnar mi...@kernel.org wrote:
* Ingo Molnar mi...@kernel.org 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
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
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
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
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
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
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
On 06/26/2015 03:23 PM, Brian Gerst wrote:
On Fri, Jun 26, 2015 at 1:52 PM, Prarit Bhargava pra...@redhat.com 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
On Fri, Jun 26, 2015 at 1:52 PM, Prarit Bhargava pra...@redhat.com 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
46 matches
Mail list logo
