From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Eric Dumazet <edumazet@google.com>, x86 <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Hugh Dickins <hughd@google.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() to schedule
Date: Mon, 26 Mar 2018 08:40:42 +0200 [thread overview]
Message-ID: <20180326064042.c6xod5n24kqttdiw@gmail.com> (raw)
In-Reply-To: <20180325141242.GC21878@pd.tnic>
* Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Mar 24, 2018 at 07:29:48AM -0700, Eric Dumazet wrote:
> > It is named gsysd, "Google System Tool", a daemon+cli that is run
> > on all machines in production to provide a generic interface
> > for interacting with the system hardware.
>
> So I'm wondering if poking at the hardware like that is a really optimal
> design. Maybe it would be cleaner if the OS would provide properly
> abstracted sysfs interfaces instead of raw MSRs.
It's not ideal to read /dev/msr.
A SysFS interface to enumerate 'system statistics' MSRs already exists via perf,
under:
/sys/bus/event_source/devices/msr/events/
This is for simple platform specific hardware statistics counters.
This is implemented in arch/x86/events/msr.c, with a number of MSRs already
abstracted out:
enum perf_msr_id {
PERF_MSR_TSC = 0,
PERF_MSR_APERF = 1,
PERF_MSR_MPERF = 2,
PERF_MSR_PPERF = 3,
PERF_MSR_SMI = 4,
PERF_MSR_PTSC = 5,
PERF_MSR_IRPERF = 6,
PERF_MSR_THERM = 7,
PERF_MSR_THERM_SNAP = 8,
PERF_MSR_THERM_UNIT = 9,
PERF_MSR_EVENT_MAX,
};
It's very easy to add new MSRs:
9ae21dd66b97: perf/x86/msr: Add support for MSR_IA32_THERM_STATUS
aaf248848db5: perf/x86/msr: Add AMD IRPERF (Instructions Retired) performance counter
8a2242618477: perf/x86/msr: Add AMD PTSC (Performance Time-Stamp Counter) support
This commit added an MSR to msr-index and added MSR event support for it as well
with proper CPU-ID dependent enumeration:
8a2242618477: perf/x86/msr: Add AMD PTSC (Performance Time-Stamp Counter) support
arch/x86/events/msr.c | 8 ++++++++
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 1 +
3 files changed, 10 insertions(+)
More complex MSR value encodings are supported as well - see for example
MSR_IA32_THERM_STATUS, which is encoded as:
/* if valid, extract digital readout, other set to -1 */
now = now & (1ULL << 31) ? (now >> 16) & 0x3f : -1;
local64_set(&event->count, now);
If an MSR counter is a plain integer counter then no such code has to be added.
Only those MSRs that are valid on a system are 'live', and thus tooling can
enumerate them programmatically and has easy symbolic access to them:
galatea:~> perf list | grep msr/
msr/aperf/ [Kernel PMU event]
msr/cpu_thermal_margin/ [Kernel PMU event]
msr/mperf/ [Kernel PMU event]
msr/smi/ [Kernel PMU event]
msr/tsc/ [Kernel PMU event]
These can be used as simple counters that are read - and it's using perf not
/dev/msr so they are fast and scalable - but the full set of perf features is also
available, so we can do:
galatea:~> perf stat -a -e msr/aperf/ sleep 1
Performance counter stats for 'system wide':
354,442,500 msr/aperf/
1.001918252 seconds time elapsed
This interface is vastly superior to /dev/msr: it does not have the various
usability, scalability and security limitations of /dev/msr.
/dev/msr is basically for debugging.
If performance matters then the relevant MSR events should be added and gsysd
should be updated to support MSR events.
Thanks,
Ingo
next prev parent reply other threads:[~2018-03-26 6:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 21:58 Eric Dumazet
2018-03-23 21:58 ` [PATCH v3 2/2] x86, cpuid: allow cpuid_read() " Eric Dumazet
2018-03-23 22:17 ` H. Peter Anvin
2018-03-24 1:01 ` Eric Dumazet
2018-03-25 22:11 ` H. Peter Anvin
2018-03-27 10:10 ` [tip:x86/cleanups] x86/cpuid: Allow " tip-bot for Eric Dumazet
2018-03-24 8:09 ` [PATCH v3 1/2] x86, msr: allow rdmsr_safe_on_cpu() " Ingo Molnar
2018-03-24 10:50 ` Thomas Gleixner
2018-03-24 14:29 ` Eric Dumazet
2018-03-25 14:12 ` Borislav Petkov
2018-03-26 1:21 ` H. Peter Anvin
2018-03-26 6:40 ` Ingo Molnar [this message]
[not found] ` <CANn89iKy_jVpBvAebJFm1UKVKfG=p+R4B1tXmC4waeK7YzZh2g@mail.gmail.com>
2018-03-26 14:23 ` Thomas Gleixner
2018-03-27 9:36 ` Ingo Molnar
2018-03-27 10:10 ` [tip:x86/cleanups] x86/msr: Allow " tip-bot for Eric Dumazet
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=20180326064042.c6xod5n24kqttdiw@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=bp@alien8.de \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®