From: Eric Dumazet <dada1@cosmosbay.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"Paul E. McKenney" <paulmck@us.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Christoph Lameter <cl@linux.com>,
linux kernel <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
David Miller <davem@davemloft.net>,
jesse.brandeburg@intel.com, netdev@vger.kernel.org,
haoki@redhat.com, mchan@broadcom.com, davidel@xmailserver.org,
Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [BUG] perf_counter: change cpu frequencies
Date: Mon, 04 May 2009 12:39:29 +0200 [thread overview]
Message-ID: <49FEC5E1.4040900@cosmosbay.com> (raw)
In-Reply-To: <20090503072535.GA9455@elte.hu>
Ingo Molnar a écrit :
> * Eric Dumazet <dada1@cosmosbay.com> wrote:
>
>> Eric Dumazet a écrit :
>>> Eric Dumazet a écrit :
>>>
>>>> But if I use plain "perf stat -a sleep 10"
>>>> it seems I get wrong values again (16 G cycles/sec) for all next perf sessions
>>>>
>>> Well, I confirm all my cpus switched from 3GHz to 2GHz, after
>>>
>>> "perf stat -a sleep 10"
>>>
>>> (but "perf stat -e instructions -e cycles -a sleep 10" doesnt trigger this problem)
>>>
>>> Nothing logged, and /proc/cpuinfo stills reports 3 GHz frequencies
>>>
>>> # cat unit.c
>>> main() {
>>> int i;
>>> for (i = 0 ; i < 10000000; i++)
>>> getppid();
>>> }
>>> # time ./unit
>>>
>>> real 0m0.818s
>>> user 0m0.289s
>>> sys 0m0.529s
>>> # perf stat -a sleep 10 2>/dev/null
>>> # time ./unit
>>>
>>> real 0m1.122s
>>> user 0m0.482s
>>> sys 0m0.640s
>>>
>>> # tail -n 27 /proc/cpuinfo
>>> processor : 7
>>> vendor_id : GenuineIntel
>>> cpu family : 6
>>> model : 23
>>> model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
>>> stepping : 6
>>> cpu MHz : 3000.102
>>> cache size : 6144 KB
>>> physical id : 1
>>> siblings : 1
>>> core id : 3
>>> cpu cores : 4
>>> apicid : 7
>>> initial apicid : 7
>>> fdiv_bug : no
>>> hlt_bug : no
>>> f00f_bug : no
>>> coma_bug : no
>>> fpu : yes
>>> fpu_exception : yes
>>> cpuid level : 10
>>> wp : yes
>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority
>>> bogomips : 6000.01
>>> clflush size : 64
>>> power management:
>>>
>>> # grep CPU_FREQ .config
>>> # CONFIG_CPU_FREQ is not set
>>>
>>>
>>> perf_counter seems promising, but still... needs some bug hunting :)
>>>
>> Update :
>>
>> Mike Galbraith suggested me to try various things, and finally, I discovered
>> this frequency change was probably a BIOS problem on my HP BL460c G1
>>
>> System Options -> Power regulator for Proliant
>>
>> [*] HP Dynamic Power Savings Mode
>> [ ] HP Static Low Power Mode
>> [ ] HP Static High Performance Mode
>> [ ] OS Control Mode
>>
>>
>> I switched it to 'OS Control Mode'
>>
>> Then acpi-cpufreq could load, and no more frequencies changes on a "perf -a sleep 10"
>> session, using or not cpufreq.
>> (Supported cpufreq speeds on these cpus : 1999 & 2999 MHz)
>>
>> So it was a BIOS issue
>
> ah! That makes quite a bit of sense. The BIOS interfering with an OS
> feature ... Was that the default setting in the BIOS?
This was default setting in BIOS, yes.
>
>> # perf stat -a sleep 10
>>
>> Performance counter stats for 'sleep':
>>
>> 80005.418223 task clock ticks (msecs)
>> 80266 context switches (events)
>> 3 CPU migrations (events)
>> 486 pagefaults (events)
>> 240013851624 CPU cycles (events) << good >>
>> 239076501419 instructions (events)
>> 679464 cache references (events)
>> <not counted> cache misses
>>
>> Wall-clock time elapsed: 10000.468808 msecs
>
> That looks perfect now.
>
> It would also be really nice to have a sysrq-p dump of your PMU
> state before you've done any profiling. Is there any trace of the
> BIOS meddling with them, that we could detect (and warn about)
> during bootup?
Difference is that on BIOS set to 'OS Control Mode' I see one more entry in ACPI list :
[ 0.000000] ACPI: SSDT cfe5b000 004C9 (v01 HP SSDTP 00000001 INTL 20030228)
...
And these 8 additional lines after (one per cpu)
[ 0.706697] ACPI: SSDT cfe5c000 002DA (v01 HP SSDT0 00000001 INTL 20030228)
[ 0.707250] ACPI: SSDT cfe5c300 002DA (v01 HP SSDT1 00000001 INTL 20030228)
[ 0.707768] ACPI: SSDT cfe5c600 002DA (v01 HP SSDT2 00000001 INTL 20030228)
[ 0.708376] ACPI: SSDT cfe5c900 002DF (v01 HP SSDT3 00000001 INTL 20030228)
[ 0.708964] ACPI: SSDT cfe5cc00 002DA (v01 HP SSDT4 00000001 INTL 20030228)
[ 0.709567] ACPI: SSDT cfe5cf00 002DA (v01 HP SSDT5 00000001 INTL 20030228)
[ 0.710122] ACPI: SSDT cfe5d200 002DA (v01 HP SSDT6 00000001 INTL 20030228)
[ 0.710713] ACPI: SSDT cfe5d500 002DA (v01 HP SSDT7 00000001 INTL 20030228)
Also, if this option is set to default (HP Dynamic Power Savings Mode) I get :
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.30-rc4-tip-01560-gdd5fa92/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device
but no kernel message logged.
Might be possible to add some kind of warning yes, I can test a patch if you want.
next prev parent reply other threads:[~2009-05-04 10:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 20:10 udp ping pong with various process bindings (and correct cpu mappings) Christoph Lameter
2009-04-24 21:18 ` Eric Dumazet
2009-04-25 15:47 ` [PATCH] net: Avoid extra wakeups of threads blocked in wait_for_packet() Eric Dumazet
2009-04-26 9:04 ` David Miller
2009-04-26 10:46 ` [PATCH] poll: Avoid extra wakeups Eric Dumazet
2009-04-26 13:33 ` Jarek Poplawski
2009-04-26 14:27 ` Eric Dumazet
2009-04-28 9:15 ` David Miller
2009-04-28 9:24 ` Eric Dumazet
2009-04-28 14:21 ` Andi Kleen
2009-04-28 14:58 ` Eric Dumazet
2009-04-28 15:06 ` [PATCH] poll: Avoid extra wakeups in select/poll Eric Dumazet
2009-04-28 19:05 ` Christoph Lameter
2009-04-28 20:05 ` Eric Dumazet
2009-04-28 20:14 ` Christoph Lameter
2009-04-28 20:33 ` Eric Dumazet
2009-04-28 20:49 ` Christoph Lameter
2009-04-28 21:04 ` Eric Dumazet
2009-04-28 21:00 ` Christoph Lameter
2009-04-28 21:05 ` Eric Dumazet
2009-04-28 21:04 ` Christoph Lameter
2009-04-28 21:11 ` Eric Dumazet
2009-04-29 9:11 ` Ingo Molnar
2009-04-30 10:49 ` Eric Dumazet
2009-04-30 11:57 ` Ingo Molnar
2009-04-30 14:08 ` Eric Dumazet
2009-04-30 16:07 ` [BUG] perf_counter: change cpu frequencies Eric Dumazet
2009-05-03 6:06 ` Eric Dumazet
2009-05-03 7:25 ` Ingo Molnar
2009-05-04 10:39 ` Eric Dumazet [this message]
2009-04-30 21:24 ` [PATCH] poll: Avoid extra wakeups in select/poll Paul E. McKenney
2009-04-29 7:20 ` Andrew Morton
2009-04-29 7:35 ` Andi Kleen
2009-04-29 7:37 ` Eric Dumazet
2009-04-29 9:22 ` Ingo Molnar
2009-04-29 7:39 ` Eric Dumazet
2009-04-29 8:26 ` Eric Dumazet
2009-04-29 9:16 ` Ingo Molnar
2009-04-29 9:36 ` Eric Dumazet
2009-04-29 10:27 ` Ingo Molnar
2009-04-29 12:29 ` Eric Dumazet
2009-04-29 13:07 ` Ingo Molnar
2009-04-29 15:53 ` Davide Libenzi
2009-04-28 9:26 ` [PATCH] net: Avoid extra wakeups of threads blocked in wait_for_packet() David Miller
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=49FEC5E1.4040900@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=davidel@xmailserver.org \
--cc=efault@gmx.de \
--cc=haoki@redhat.com \
--cc=hpa@zytor.com \
--cc=jesse.brandeburg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchan@broadcom.com \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=paulus@samba.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 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.