Date: Fri, 25 Sep 2015 16:09:18 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Arthur van der Peijl <aavanderpeijl@gmail.com> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: ACPI problems op ASrock Message-ID: <CAN6yY1s1akH6Wva-1eyYt3AZWRvvE%2BiSLtydDdfc01OwwOaZwg@mail.gmail.com> In-Reply-To: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl <
aavanderpeijl@gmail.com> wrote:
> Hello,
>
> In May I started with 10.0-Release on an ASrock E3C224D4I-14S.
> The system had low power consumption and powerd(8) did a good job lowering
> the CPU frequency.
>
> However starting from 10.1 (and now 10.2-release) I keep getting high CPU
> consumption due to a process called {acpi task}.
>
> BIOS upgrades or changes didn't help. Disabling ACPI results in system
> halt at startup.
> Does anybody have an idea to solve this? It seems that the ACPI process in
> FreeBSD is changed, which my motherboard cannot handle (or the mb has wrong
> ACPI tables?).
>
> top -SH output:
> ----
> last pid: 41184; load averages: 1.71, 1.75, 1.64
> up 8+14:05:40 10:00:16
> 691 processes: 7 running, 663 sleeping, 21 waiting
> CPU: 0.8% user, 0.0% nice, 62.7% system, 0.0% interrupt, 36.5% idle
> Mem: 90M Active, 4310M Inact, 11G Wired, 18M Cache, 144K Buf, 497M Free
> ARC: 9991M Total, 1364M MFU, 7997M MRU, 4841K Anon, 36M Header, 588M Other
> Swap: 2048M Total, 2048M Free
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 11 root 155 ki31 0K 32K RUN 1 122.7H 62.99%
> idle{idle: cpu1}
> 0 root 8 0 0K 7088K RUN 1 73.2H 36.87%
> kernel{acpi_task_1}
> 0 root 8 0 0K 7088K RUN 0 73.3H 36.18%
> kernel{acpi_task_0}
> 0 root 8 0 0K 7088K RUN 0 73.2H 35.60%
> kernel{acpi_task_2}
> 11 root 155 ki31 0K 32K RUN 0 67.6H 34.08%
> idle{idle: cpu0}
> 1024 mysql 20 0 266M 69624K RUN 1 0:37 0.10%
> mysqld{mysqld}
> 12 root -60 - 0K 336K WAIT 0 11:18 0.00%
> intr{swi4: clock}
> 1149 root 20 0 500M 90016K sbwait 0 6:15 0.00%
> mongod{mongod}
> 1149 root 20 0 500M 90016K sbwait 1 6:13 0.00%
> mongod{mongod}
> 1149 root 20 0 500M 90016K sbwait 0 6:12 0.00%
> mongod{mongod}
> 687 root 20 0 4560M 363M uwait 1 5:31 0.00%
> java{java}
> ----
>
> Regards,
>
> Arthur
>
I have not noted this exact behavior, so this MIGHT not work, but the
subject of power management seems to keep coming up. For a good discussion
of the subject, read mav@'s FreeBSD wiki article
<https://wiki.freebsd.org/TuningPowerConsumption>; on the subject. It's
slightly (but only slightly) dated.
To fix your immediate issue, try adding the following to /etc/rc.conf:
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
NOTE: In the case of very large multiprocessor systems with 32 or more
CPUs, you might get a nasty performance hit and should instead use:
performance_cx_lowest="C2"
economy_cx_lowest="Cmax"
Please DON'T enable TCC and/or throttling and C-states together! On some
processors this can cause deadlocks. Intel never expected TCC/throttling to
be used the way FreeBSD did.
For desktop and laptop use, "Cmax" is always the way to go. It really,
really reduces power consumption.
Finally, if this fails, you can restore TCC by adding
"hint.acpi_p4tcc.0.disabled=0" to /boot/loader.conf, but never combine this
with setting either cx_lowest value in rc.conf. This change will require a
reboot.
You can change this on a running system with "sysctl
dev.cpu.0.cx_lowest=C8" to enable C-states or C1 to disable them. No need
to re-boot.
Read on for more gory details. Note that I am at least partly responsible
for the long-term brokenness of FreeBSD power management as I did
laboratory testing of it when I was at Lawrence Berkeley Lab, but did not
really understand the differences between the test-bed and the real world.
Throttling is not and never has been a tool for power management. It was
created by Intel as a method of thermal management and the implementation
was manual. That is, some external process had to activate it. It was
replaced in 2000 by TCC (Thermal Control Circuit) which did the exact same
thing, but was entirely internal to the processor and was thus consistent
and uniformly implemented. Throttling was still present for compatibility,
but is really, really obsolete.
Both throttling and TCC so the same thing. They reduce the heat generated
by skipping 'N' of every 8 clock cycles. They don't actually change the
clock speed. EST, which actually does slow the clock as well as reducing
the core voltage should still provide a a few clock speeds. The number is
dependent on the particular CPU, but usually between 3 and 8. It does save
power, but not very effectively.
Unfortunately, many thought that throttling was a way to do power
management. In fact, except in a few real-time edge cases, it is totally
ineffective for that purpose.
The problem you are having is probably that enabling the newer, really
effective power management tool was not committed to 10.2 when TCC was
disabled. It is now in HEAD and I am hoping to see it in 10.3 as well as
11. (I'm not a committer, so I only can go on what I've been told by the
one who committed disabling TCC.)
C-states do not change the clock speed. You will only have a small set of
frequencies reported as those will be REAL clock speeds from EST, not the
synthetic ones shown when using throttling/TCC, so the number of them shown
by default on 10.2 will be 1/8th of when was shown by prior versions.
I you do need to do this, please let us know. That should not be happening!
I am now working (slowly) on a power management section of the handbook
which will do a better job of explaining the issues.
--
Kevin Oberman, Part time goatherd and retired Network Engineer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1s1akH6Wva-1eyYt3AZWRvvE%2BiSLtydDdfc01OwwOaZwg>