From owner-freebsd-acpi@freebsd.org Fri Sep 25 23:09:19 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 37ECAA081E8 for ; Fri, 25 Sep 2015 23:09:19 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 F134D1E48 for ; Fri, 25 Sep 2015 23:09:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by oibi136 with SMTP id i136so66260790oib.3 for ; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uxvQ+a5u3nefAh/+APG4pn6Wdj/sb1RHTOwLxmpUAsM=; b=rbM571BvTEb0t7qYN7d1mAFxGcOK+TOuINAA0gzmLmh6U68HkzjafYXwanvnezNIbu 9UhnQuyxtnIjZ1W64P+UbzFDqIYZeXyfXULcl9LPAyFExN9fDy2VdgaKUtnNYBiWdCm7 xsRH+OViv04g7FhCBjAzJMRkwFNsw0etvA09U2SjnaUSzw/h1SFSv11QtPrVWH5JWvPg wmsljHcNugx6yNqlsN3oBBUXxUfzSaKeJ624SPtLP/awD/ikGH/yThjucpDDeC9/APCl YJSONDAk3eTvY8pYW+QrEPOrjlIBcuejh8V01tNG0lc+v791n7E7zSeKnzDDltGTzz8r kgAQ== MIME-Version: 1.0 X-Received: by 10.202.182.87 with SMTP id g84mr4350681oif.59.1443222558268; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.202.102.9 with HTTP; Fri, 25 Sep 2015 16:09:18 -0700 (PDT) In-Reply-To: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> References: <49E6B533-4457-4583-82A2-9940C291AB51@gmail.com> Date: Fri, 25 Sep 2015 16:09:18 -0700 X-Google-Sender-Auth: q7hjIJTKGCZVdgNvxN14KnkOLVw Message-ID: Subject: Re: ACPI problems op ASrock From: Kevin Oberman To: Arthur van der Peijl Cc: "freebsd-acpi@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Fri, 25 Sep 2015 23:09:19 -0000 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 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