linux-kernel - RE: perf_counter Atom patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9F0C1DB20AFA954FA1DA05309350433D7B2584D1@pdsmsx503.ccr.corp.intel.com>
Date:	Tue, 23 Jun 2009 11:38:36 +0800
From:	"Wang, Yong Y" <yong.y.wang@...el.com>
To:	"eranian@...il.com" <eranian@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>
Subject: RE: perf_counter Atom patch

> From: stephane eranian [mailto:eranian@...glemail.com] 
> 
> I would like to better understand what makes you think
> this is the case.
> 

Because I observed that the output of 'perf stat -e 0:0 -e 0:1 -e 0:6 <cmd>'
is always like below without the quirk.

 Performance counter stats for '<cmd>':

              0  cycles
              0  instructions
              0  bus-cycles

> Perfmon is working on Atom and there, fixed counters work perfectly:
> $ head -6 /proc/cpuinfo
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 28
> model name	: Intel(R) Atom(TM) CPU  230   @ 1.60GHz
> stepping	: 2
> ...

My cpuinfo is below and the only difference I can see is 270 vs 230.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
stepping        : 2

> $ pfmon -v --us-c -e
> unhalted_core_cycles,unhalted_reference_cycles,instructions_retired
> noploop 10
> [FIXED_CTRL(pmc16)=0xaaa pmi0=1 en0=0x2 any0=0 pmi1=1 en1=0x2 any1=0
> pmi2=1 en2=0x2 any2=0] INSTRUCTIONS_RETIRED UNHALTED_CORE_CYCLES
> UNHALTED_REFERENCE_CYCLES
> [FIXED_CTR0(pmd16)]
> [FIXED_CTR1(pmd17)]
> [FIXED_CTR2(pmd18)]
> noploop for 10 seconds
> 15,902,604,169 UNHALTED_CORE_CYCLES
> 15,902,586,180 UNHALTED_REFERENCE_CYCLES
> 7,941,842,505 INSTRUCTIONS_RETIRED
> 

Could you pls try to revert my patch, run 'perf stat -e 0:0 -e 0:1 -e 0:6 <cmd>' and see
whether the counters count or not? I tried pfmon on my atom box but it always runs into
segfault. If the fixed counters work for you, I will ask Atom hw foks here in Intel why this
is the case and revise the code accordingly.

> 
> I seem to recall that what may be bogus on Atom is what is returned by
> CPUID(0xa)
> for the fixed counters. But they are there and they work. Thus, I
> believe, the quirk
> should be  at the location where CPUID(0xa) is invoked not 
> where you've put it.
> 

The return value of CPUID(0xa) is indeed bogus, too and there is another quirk for that in
intel_pmu_init() in arch/x86/kernel/cpu/perf_counter.c

x86_pmu.num_counters_fixed      = max((int)edx.split.num_counters_fixed, 3);

Is this what you were talking about?--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/