ACPI slowing CPU... or something else

youshi10 at u.washington.edu youshi10 at u.washington.edu
Thu Jul 26 01:04:11 UTC 2007


On Wed, 25 Jul 2007, V.I.Victor wrote:

> On Wed, 25 Jul 2007 youshi10 at u.washington.edu wrote:
>
>> On Wed, 25 Jul 2007, V.I.Victor wrote:
>>
>>> On Wed, 25 Jul 2007, Garrett Cooper wrote:
>>>
>>>> V.I.Victor wrote:
>>>>>  I've two 5.4 desktop boxes.  Pretty much the same installation; both
>>>>>  from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
>>>>>  ssh (command-line only w/no gui) and otherwise lightly loaded.
>>>>>
>>>>>  Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
>>>>>         avail memory = 121630720 (115 MB)
>>>>>         ACPI disabled by blacklist.
>>>>>
>>>>>  Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU)
>>>>>         avail memory = 252186624 (240 MB)
>>>>>         cpu0: <ACPI CPU> on acpi0
>>>>>         acpi_throttle0: <ACPI CPU Throttling> on cpu0
>>>>> ...
>>>
>>>> Yes. On my virtual machine with ACPI:
>>>>
>>>> dev.cpu.0.freq: 2653
>>>> dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1
>>>> 331/-1
>>>>
>>>> [root at optimus-vm-7 ~]# dmesg | grep 26
>>>> FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
>>>> CPU: Intel(R) Core(TM)2 CPU          6700  @ 2.66GHz (2666.79-MHz K8-class
>>>> CPU)
>>>> Timecounter "TSC" frequency 2666794890 Hz quality 800
>>>>
>>>> What are the following sysctls set to?
>>>>
>>>> kern.clockrate
>>>> hw.acpi.cpu.cx_lowest
>>>> dev.cpu.0.cx_lowest
>>>> dev.cpu.0.cx_usage
>>>
>>> Thanks for the reply!  I don't seem to have the last 2 you've asked about.
>>>
>>> 'sysctl -a | egrep "clockrate|cpu"' reported the following:
>>>
>>> kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }
>>> kern.threads.virtual_cpu: 1
>>> kern.ccpu: 1948
>>> kern.smp.maxcpus: 1
>>> kern.smp.cpus: 1
>>> hw.ncpu: 1
>>> hw.clockrate: 1794
>>> hw.acpi.cpu.cx_supported: C1/0
>>> hw.acpi.cpu.cx_lowest: C1
>>> hw.acpi.cpu.cx_usage: 100.00%
>>> machdep.cpu_idle_hlt: 1
>>> dev.cpu.0.%desc: ACPI CPU
>>> dev.cpu.0.%driver: cpu
>>> dev.cpu.0.%location: handle=\_PR_.CPU0
>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0
>>> dev.cpu.0.%parent: acpi0
>>> dev.cpu.0.freq: 1796
>>> dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1 449/-1 224/-1
>>> dev.acpi_throttle.0.%parent: cpu0
>>> dev.cpufreq.0.%driver: cpufreq
>>> dev.cpufreq.0.%parent: cpu0
>>
>>
>>
>> Do you have SMP enabled?
>
> No.  Both boxes have pretty minimal, basic installations.
>
>> You also might be able to tune the kernel clock rate to obtain better
>> performance; I forget what the values were for sysctl, but if you search
>> around the current@ archives a bit, there was a discussion involving VMware
>> and clock tuning approximately 2-3 months ago which details this issue, and
>> possible solutions.
>
> Perhaps tuning could help.  I'll check the archives.
>
> However, it just seems to me that the 1.8 GHz box ought to perform the simple prog (orig post) at least as fast as the 6 MHz box.

Depends on:
1. What you're trying to do.
2. What your programs are optimized for.
3. Additional factors (I/O, load, etc).
4. Hardware attached to each machine. Some examples...
    a. Comparing a SCSI disk vs a PATA disk.
    b. Clockspeed applied to the RAM on one machine isn't equal to the other.
    c. Motherboard manufacturers -- some manufacturers have done a shoddy job with memory handling, BIOS manufacturing, and other critical stats in the past.

Try disabling ACPI on the P4 though and see what happens. I will say though, the Willamette (1st gen P4) chips weren't Intel's finest desktop chip; some people went far enough to complain that the Willamette series was nothing more than overclocked Coppermines, i.e. P3's. I haven't taken a look at the architectures and compared them, so those may be empty claims.

You'll get performance with a Northwood or Prescott series P4 processor though, in particular the later revisions of both chips, once they introduced Hyperthreading.

And remember, operating frequency of a CPU doesn't mean everything; it's just a ballpark figure for performance ;).

Finally, quite a few advancements have been made going from 5.4 to 6.2. I'd say give 6.2 (and soon 7-BETA/-RELEASE) a try before ruling out a major problem with your PC(s), or FreeBSD (overall).

-Garrett



More information about the freebsd-questions mailing list