Re: Updating the tuning man page

From: jb <jb.1234abcd_at_gmail.com>
Date: Tue, 27 Mar 2012 08:57:10 +0000 (UTC)
Kevin Oberman <kob6558 <at> gmail.com> writes:

> 
> On Mon, Mar 26, 2012 at 8:55 PM, Eitan Adler <lists <at> eitanadler.com> wrote:
> > As some of you may know there is/was an effort to rewrite the tuning
> > man page at http://wiki.freebsd.org/SystemTuning .
> > Feel free to email me with any questions.
> ...
> Should tuning include discussion of tuning for power management? Even
> server operators are becoming aware of the need for power management
> and the only really good information on it is mav's excellent wiki
> page. From queries about the subject, most people really don't
> understand the concepts and do the wrong thing. Frankly, FreeBSD does
> the wrong thing by default, as mav pointed out.

I agree.
The wiki page at
http://wiki.freebsd.org/TuningPowerConsumption
could be improved as well.

These are my notes - feel free to include them in tuning(7) and wiki.

http://wiki.freebsd.org/TuningPowerConsumption
POWERD(8), TUNING(7)

A processor frequency (ticks per second) determines how much work (instructions
processed per second) can be done.
CPU-bound (intensive) tasks can run faster with higher CPU frequency.
More work done (more tasks per second) causes more switchings in integrated
circuits, which consumes more current, which causes more power consumption.
Even when no CPU tasks are performed (idle state), higher CPU frequency causes
some power consumption.
>From the source of power point of view (AC or battery), higher voltage enables
higher power supply, but in turn also possible power consumption.
In order to reduce power consumption, it is advantageous to modulate CPU
frequency and its voltage when:
- CPU is idle
- when CPU performs tasks (by optimizing based on curve of power consumption)
- power supply comes from a battery
- increased work load causes increased thermal load and dissipation and loss of
  energy (increased power consumption)

The power management works by modulating CPU frequency and voltage by means of:
- CPU states control
  - P-states (CPU performance states)
    They are defined by ACPI specs.
    They determine the ability of a working CPU (under load) to save power
    consumption and reduce the peak thermal load.
    To operate at any P-state, the CPU must be in the C0 operational state
    where the processor is working (under load) and not idling.
    The number of P-states is processor specific.
    Both frequency and voltage are scaled as the P-state changes. 
    Higher P-state numbers represent lower frequencies (slower processor
    speeds).
    Power consumption is lower at higher P-states.
  - C-states (operating states)
    They are defined by ACPI specs.
    They determine an ability of an idle CPU to turn off unused components to
    save power.
    They are idle CPU states, except C0 in which the CPU is active (under
    load).
    Higher C-state numbers represent deeper CPU sleep states, at which
    correspondingly more components shut down to save power.
    Some components that are shut down include stopping the CPU clock and
    stopping interrupts. A disadvantage is that deeper sleep states have slower
    wakeup times.
    C1 is the default state.
  NOTE:
  P-states and C-states are orthogonal (each can vary independently of
  the other).
- thermal control
  The CPU Frequency Thermal Control, also called throttling, can be implemented
  via an older external mechanism or via TCC (also called P4TCC).

$ sysctl -e dev.cpu
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=300
dev.cpu.0.freq_levels=1867/35000 1633/30625 1600/30000 1400/26250 1333/25000
1166/21875 1067/20000 933/17500 800/16000 700/14000 600/12000 500/10000 400/8000
300/6000 200/4000 100/2000
dev.cpu.0.cx_supported=C1/1 C2/1 C3/17
dev.cpu.0.cx_lowest=C1
dev.cpu.0.cx_usage=100.00% 0.00% 0.00% last 3302us
dev.cpu.1.%desc=ACPI CPU
dev.cpu.1.%driver=cpu
dev.cpu.1.%location=handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo=_HID=none _UID=0
dev.cpu.1.%parent=acpi0
dev.cpu.1.cx_supported=C1/1 C2/1 C3/17
dev.cpu.1.cx_lowest=C1
dev.cpu.1.cx_usage=100.00% 0.00% 0.00% last 2062us

$ sysctl -e dev.p4tcc
dev.p4tcc.0.%desc=CPU Frequency Thermal Control
dev.p4tcc.0.%driver=p4tcc
dev.p4tcc.0.%parent=cpu0
dev.p4tcc.0.freq_settings=10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1
dev.p4tcc.1.%desc=CPU Frequency Thermal Control
dev.p4tcc.1.%driver=p4tcc
dev.p4tcc.1.%parent=cpu1
dev.p4tcc.1.freq_settings=10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1
2500/-1 1250/-1

$ sysctl -a |grep acpi
...

Power management with powerd daemon (P-states and C-states):
------------------------------------------------------------
The default mode is adaptive for battery and hiadaptive for other (AC power).
$ ps auxww | grep -i powerd
root        1799   0.0  0.0   9612    852  ??  Ss   Sat06AM     8:12.95
/usr/sbin/powerd

An example of user configuration (not that I need it; be careful of using
non-default values as they may break the system components).
/etc/rc.conf: 
powerd_flags="-n hadp"
performance_cx_lowest="C2"
economy_cx_lowest="C2"
performance_cpu_freq="HIGH"

Test:
-----
- measure dev.cpu.0.freq
- measure dev.cpu.0.freq during compilation
- measure dev.cpu.0.freq while disk quiet
  'top' to report near 100% idle
- measure dev.cpu.0.freq after few seconds

jb
Received on Tue Mar 27 2012 - 07:12:28 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC