From owner-freebsd-acpi@freebsd.org Sat Sep 26 08:17:25 2015 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73E8E9B81B4 for ; Sat, 26 Sep 2015 08:17:25 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE6D91C8 for ; Sat, 26 Sep 2015 08:17:24 +0000 (UTC) (envelope-from aavanderpeijl@gmail.com) Received: by wicge5 with SMTP id ge5so47023833wic.0 for ; Sat, 26 Sep 2015 01:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3BvReGBL7DGqcOBSatf7Z14S+51Q7RftEOszgo8YP6k=; b=H9aagUfXTQaee0Pf4UUVcIco9lN0dTu6QGRrWrKgzSVDCNW9XHYQEU3CCEBCoU9+8p GuZEr7IsEPnIhpOWjwR3xgJ/H/j8WflZq8eZF2raCAO6htnbjHLF0orpsBmTwsBxJAWl F6mwO6SSR/0//cWT2n1AP6BgdqK16qKXNhO/7MT9uyooqAXTeBYXnGTPgJWDVmsOLbZp 5lk4W0dLo+/jYpPI4kcf9hdZdqOtG5f4GKhb3axAVHnLt4mERwSK1YqIbcOelnf7i81j BTBmKcpmU0lfX3JyPcIz0OEuB4OIcBDN1n9dkyL2C1B/t1CkBmDE37kmEFYOg6u5tUJ2 Q1eA== X-Received: by 10.180.87.102 with SMTP id w6mr8143930wiz.88.1443255443079; Sat, 26 Sep 2015 01:17:23 -0700 (PDT) Received: from macbookderpeijl.aerrow.local ([62.238.6.31]) by smtp.gmail.com with ESMTPSA id ex17sm7127975wid.23.2015.09.26.01.17.21 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Sep 2015 01:17:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: ACPI problems op ASrock From: Arthur van der Peijl In-Reply-To: Date: Sat, 26 Sep 2015 10:17:20 +0200 Cc: "freebsd-acpi@freebsd.org" Message-Id: References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> To: Kevin Oberman X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 08:17:25 -0000 Thank you for assistance: powerd must clearly not be my focus: the CPU = stays high and thus cannot go into idle mode. I worked thought the document which uncovers that most settings are = already available in my system: [root@zfsguru /home/ssh]# cat /etc/rc.conf | grep cx_ performance_cx_lowest=3D"Cmax" economy_cx_lowest=3D"Cmax" =20 No need to change performance_cx_lowest as I just have a Pentium G3220 = running. [root@zfsguru /home/ssh]# cat /boot/loader.conf | grep hint. hint.p4tcc.0.disabled=3D"1" hint.acpi_throttle.0.disabled=3D"1" Tried to change lowest level on running system:=20 [root@zfsguru /home/ssh]# sysctl dev.cpu.0.cx_lowest=3DC8 dev.cpu.0.cx_lowest: C8 -> C8 We're already there. The document described some other setting which = could be read: [root@zfsguru /home/ssh]# sysctl dev.cpu | grep cx dev.cpu.1.cx_usage: 100.00% last 5us dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_supported: C1/1/1 dev.cpu.0.cx_usage: 100.00% 0.00% last 4us dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/117 I don't inderstand this. 100% CPU is my main issue, created by = {acpi_task} in the kernal. However -> CPU1 supports different states as CPU0? Or is this a summary = of last states? You last remark about frequencies: [root@zfsguru /home/ssh]# sysctl dev.cpu | grep freq dev.cpu.0.freq_levels: 3000/53000 2900/50301 2700/46082 2600/43525 = 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 = 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550 dev.cpu.0.freq: 3000 As I understand there could be better effective power management be = available. Should that resolve my high CPU issue? Or is it caused by bad = Asrock BIOS tables?=20 As only my high CPU generating {acpi_task} stops, I'll get a better - = more power effective - system using less Watts. Regards, Arthur Op 26 sep. 2015, om 01:09 heeft Kevin Oberman het = volgende geschreven: > On Fri, Sep 25, 2015 at 11:39 AM, Arthur van der Peijl = wrote: > Hello, >=20 > 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. >=20 > However starting from 10.1 (and now 10.2-release) I keep getting high = CPU consumption due to a process called {acpi task}. >=20 > 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?). >=20 > 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 >=20 > 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} > ---- >=20 > Regards, >=20 > Arthur >=20 > 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 on the = subject. It's slightly (but only slightly) dated. >=20 > To fix your immediate issue, try adding the following to /etc/rc.conf: > performance_cx_lowest=3D"Cmax" > economy_cx_lowest=3D"Cmax" >=20 > 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=3D"C2" > economy_cx_lowest=3D"Cmax" >=20 > 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. >=20 > For desktop and laptop use, "Cmax" is always the way to go. It really, = really reduces power consumption. >=20 > Finally, if this fails, you can restore TCC by adding = "hint.acpi_p4tcc.0.disabled=3D0" to /boot/loader.conf, but never combine = this with setting either cx_lowest value in rc.conf. This change will = require a reboot. >=20 > You can change this on a running system with "sysctl = dev.cpu.0.cx_lowest=3DC8" to enable C-states or C1 to disable them. No = need to re-boot. >=20 > 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.=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.) >=20 > 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. >=20 > I you do need to do this, please let us know. That should not be = happening! >=20 > 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 >=20 >=20