public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Imre Palik <imrep.amz@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Paul Mackerras <paulus@samba.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org, "Palik, Imre" <imrep@amazon.de>,
	Anthony Liguori <aliguori@amazon.com>
Subject: Re: [RFC PATCH] perf: honoring cpuid for number of fixed counters
Date: Thu, 04 Jun 2015 12:35:08 +0200	[thread overview]
Message-ID: <557029DC.6080201@gmail.com> (raw)
In-Reply-To: <20150603083615.GZ3644@twins.programming.kicks-ass.net>

On 06/03/15 10:36, Peter Zijlstra wrote:
> On Wed, Jun 03, 2015 at 10:03:48AM +0200, Imre Palik wrote:
>> From: "Palik, Imre" <imrep@amazon.de>
>>
>> perf doesn't seem to honor the number of fixed counters specified by cpuid
>> leaf 0xa.  It always assume that intel CPUs have at least 3 fixed counters.
>>
>> So if some of the fixed counters are masked out by the hypervisor, it still
>> tries to check/set them.  This is good for testing the masking code in the
>> hypervisor, but not so nice otherwise.
>>
>> This patch makes perf pehave somewhat nicer when the number of fixed
>> counters is less than three.
> 
>> @@ -3042,13 +3042,6 @@ __init int intel_pmu_init(void)
>>  
>>  	x86_pmu.max_pebs_events		= min_t(unsigned, MAX_PEBS_EVENTS, x86_pmu.num_counters);
>>  
>> -	/*
>> -	 * Quirk: v2 perfmon does not report fixed-purpose events, so
>> -	 * assume at least 3 events:
>> -	 */
>> -	if (version > 1)
>> -		x86_pmu.num_counters_fixed = max((int)edx.split.num_counters_fixed, 3);
>> -
>>  	if (boot_cpu_has(X86_FEATURE_PDCM)) {
>>  		u64 capabilities;
> 
> So the problem is that there is real hardware out there that gets the
> CPUID stuff wrong, and this patch penalizes that by then not using the
> fixed counters.

I haven't thought about this.  Thanks.

> Further, the Intel Arch PerfMon v2 spec actually specifies there to be 3
> fixed function counters.
> 
> So anything that says it is v2+ and does not have the 3, is non
> compliant.
>
> I would suggest you go fix your hypervisor.

If I set up the hypervisor to advertise Arch PerfMon v1 (0 fixed counters), then  without my patch, perf still tries to use fixed counters.  So something is clearly broken here.

> Lacking that option; you could probe the MSRs to see if they're really
> there using wrmsr_safe() or something like that -- see
> check_hw_exists().

I'll send something along these lines soon.

  reply	other threads:[~2015-06-04 10:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-03  8:03 [RFC PATCH] perf: honoring cpuid for number of fixed counters Imre Palik
2015-06-03  8:36 ` Peter Zijlstra
2015-06-04 10:35   ` Imre Palik [this message]
2015-06-04 11:49     ` Peter Zijlstra
2015-06-04 12:30       ` Imre Palik
2015-06-04 13:29         ` Peter Zijlstra
2015-06-05 13:02           ` Imre Palik

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=557029DC.6080201@gmail.com \
    --to=imrep.amz@gmail.com \
    --cc=acme@kernel.org \
    --cc=aliguori@amazon.com \
    --cc=hpa@zytor.com \
    --cc=imrep@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --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