From: Borislav Petkov <bp@alien8.de>
To: George Spelvin <linux@horizon.com>
Cc: mcfadden8@llnl.gov, a.p.zijlstra@chello.nl, acme@infradead.org,
ak@linux.intel.com, andriy.shevchenko@linux.intel.com,
brgerst@gmail.com, dan.j.williams@intel.com, dyoung@redhat.com,
hpa@zytor.com, jolsa@redhat.com, linux-kernel@vger.kernel.org,
luto@kernel.org, mingo@kernel.org, mingo@redhat.com,
pavel@ucw.cz, tglx@linutronix.de, viro@zeniv.linux.org.uk,
x86@kernel.org, yu.c.chen@intel.com
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction
Date: Mon, 29 Feb 2016 19:20:47 +0100 [thread overview]
Message-ID: <20160229182047.GD3724@pd.tnic> (raw)
In-Reply-To: <20160229175318.14183.qmail@ns.horizon.com>
On Mon, Feb 29, 2016 at 12:53:18PM -0500, George Spelvin wrote:
> I worry that this is this too ambitious a goal. Who is volunteering
> to actually do this?
>From a quick look, the stuff in the examples was already in the rapl
driver.
> It takes quite a while to find a good OS-level abstraction (remember
> wakelocks?), and MSRs are the CPU architect's equivalent of ioctls.
> So they're a bit of a mess, and there will keep being new ones.
And yet you end up needing only a handful in most cases.
> I agree with you about anything that's going to see widespread use, but
> for specialized (apparently mostly HPC) use where the application really
> is heavily optimized for specific CPU models, perhaps dangerous-but-simple
> is good enough?
If it is that specialized, then it doesn't belong upstream.
> The proposed interface is simple and imposes very little maintenance
> burden on the kernel. My main objection is that it's yet another
> special-case permission system. Are we *sure* we'll never want to have
> to classes of users with different access rights?
The proposed interface is the wrong thing to do. There's no need to talk
about how simple and less of a burden it is.
The burden comes when people start complaining about strange issues and
we go and have to get a full MSR dump at the time the explosion happens
because some userspace tool went nuts and scribbled all over them. No
one wants to be on the receiving end of a bug report like this.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
next prev parent reply other threads:[~2016-02-29 18:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 0:02 [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Marty McFadden
2016-02-26 0:02 ` [PATCH 1/4] MSR: Prep for separating msr.c into three files Marty McFadden
2016-02-26 2:56 ` kbuild test robot
2016-02-26 10:08 ` Andy Shevchenko
2016-02-26 0:02 ` [PATCH 2/4] " Marty McFadden
2016-02-26 0:02 ` [PATCH 3/4] MSR: msr Whitelist Implementation Marty McFadden
2016-02-26 1:05 ` kbuild test robot
2016-02-26 1:05 ` [PATCH] MSR: fix badzero.cocci warnings kbuild test robot
2016-02-26 0:02 ` [PATCH 4/4] MSR: msr Batch processing feature Marty McFadden
2016-02-26 2:48 ` Andy Lutomirski
2016-03-03 17:21 ` One Thousand Gnomes
2016-03-03 23:09 ` Mcfadden, Marty Jay
2016-02-26 7:37 ` [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Ingo Molnar
2016-02-28 18:54 ` Mcfadden, Marty Jay
2016-02-28 19:01 ` Borislav Petkov
2016-02-29 2:55 ` Mcfadden, Marty Jay
2016-02-29 14:58 ` Borislav Petkov
2016-02-29 16:31 ` Henrique de Moraes Holschuh
2016-02-29 17:22 ` Borislav Petkov
2016-02-29 17:53 ` George Spelvin
2016-02-29 18:20 ` Borislav Petkov [this message]
2016-02-29 22:35 ` Mcfadden, Marty Jay
2016-02-29 23:41 ` Borislav Petkov
2016-03-01 19:01 ` Rountree, Barry L.
2016-03-03 0:40 ` Andy Lutomirski
2016-03-01 8:02 ` Thomas Gleixner
2016-03-01 18:29 ` Rountree, Barry L.
2016-03-01 18:38 ` Borislav Petkov
2016-02-29 17:17 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160229182047.GD3724@pd.tnic \
--to=bp@alien8.de \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=ak@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgerst@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=luto@kernel.org \
--cc=mcfadden8@llnl.gov \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.