From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 8 10:22:58 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B55B106566B; Sun, 8 Jul 2012 10:22:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 04F198FC19; Sun, 8 Jul 2012 10:22:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA22884; Sun, 08 Jul 2012 13:22:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Snodg-000Gt5-2H; Sun, 08 Jul 2012 13:22:52 +0300 Message-ID: <4FF95F79.30309@FreeBSD.org> Date: Sun, 08 Jul 2012 13:22:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: "freebsd-acpi@freebsd.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Vitaly Magerya , John Baldwin , Giovanni Trematerra Subject: improve cx_lowest logic X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 10:22:58 -0000 I would like to propose the following change for review and testing: http://people.freebsd.org/~avg/acpi_cpu_cx_lowest.diff The idea is to separate effective cx_lowest (the limit that the idling code should not currently exceed) from user-set cx_lowest limit/target. Specifically, this addresses dynamic C-state changes by ACPI platform. Currently if a user sets cx_lowest to, say, C3, then available C-states change so that C2 is the deepest available C-state and cx_lowest gets overridden to C2 and all memory of C3 setting is lost. Also, there is a problem with asynchronous nature of userland notification about power profile change and kernel notifications of _CST changes for each CPU in SMP system. That required work-arounds like one in r209213 which also introduced quite a bit of confusion about how per-CPU cpu_cx_lowest, global cpu_cx_lowest and dynamic C-state changes interact with each other. To this day I can not unwind the complete logic behind the following lines: if (sc->cpu_cx_lowest < cpu_cx_lowest) acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); So to avoid the problems described above I decided to split the cx_lowest limit into the persistent user-set limit, cpu_cx_lowest_lim, and dynamic effective limit. The logic to set cpu_cx_lowest based on cpu_cx_lowest_lim and cpu_cx_count is moved to acpi_cpu_set_cx_lowest(). Note that per-CPU cpu_cx_lowest_lim does not "interact" with global cpu_cx_lowest_lim. Whichever is set later (via sysctl) just overrides the other. With such a change it no longer makes sense to limit allowed cx_lowest sysctl values to currently available C-state levels. Indeed, if a user knows that his system may provide C6 under some circumstance, but currently only C1 is available, then there is no reason to disallow setting cx_lowest sysctl (cpu_cx_lowest_lim) to C6. So values up to MAX_CX_STATES are allowed. After this change cpu_cx_count _global_ variable became unused (write-only) and was removed. Additionally, I introduced magic value of "Cmax" for cx_lowest sysctls to mean that there should not be any limit on C-state depth. The change is partially based on submission from Vitaly: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6892 -- Andriy Gapon