Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbbF1OeP (ORCPT ); Sun, 28 Jun 2015 10:34:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33488 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752217AbbF1OeJ (ORCPT ); Sun, 28 Jun 2015 10:34:09 -0400 Message-ID: <559005DD.3070003@redhat.com> Date: Sun, 28 Jun 2015 10:34:05 -0400 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: Andy Lutomirski CC: Ingo Molnar , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , X86 ML , Len Brown , Dasaratharaman Chandramouli , Peter Zijlstra , Borislav Petkov , Andy Lutomirski , Denys Vlasenko , Brian Gerst , Arnaldo Carvalho de Melo Subject: Re: [PATCH] x86, msr: Allow read access to /dev/cpu/X/msr References: <1435341131-3279-1-git-send-email-prarit@redhat.com> <20150627083354.GA12834@gmail.com> <20150627083921.GA13074@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2172 Lines: 63 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 >>> perf features that can be used around this. (sampling, counting, call chains, >>> etc.) >> >> See below code from Andy that exposes a single MSR via perf. At the core of the >> PMU driver is a single rdmsrl(): >> >> +static void aperfmperf_event_start(struct perf_event *event, int flags) >> +{ >> + u64 now; >> + >> + rdmsrl(event->hw.event_base, now); >> + local64_set(&event->hw.prev_count, now); >> +} >> I just sat down to do something similar to what Andy had proposed here :). >> Now I think what we really want is to expose not a single MSR but multiple MSRs in >> a single driver, i.e. don't have one PMU driver per MSR, but have a driver that >> allows the exposure of select MSRs as counters. > > I'm way ahead of you: this driver can expose *two* MSRs as counters :) > > 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 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. > > This driver only knows how to handle counters, though. I'm not sure > whether all of the MSRs that turbostat needs are counters. I knew that turbostat only did MSR reads and that's why turbostat's code was changed in this patch. TBH I'm more concerned for software that monitors system power consumption, performance, and load. I'll take what Andy has proposed and expand on it. P. > > --Andy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/