Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267810AbUIUQZE (ORCPT ); Tue, 21 Sep 2004 12:25:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267818AbUIUQZE (ORCPT ); Tue, 21 Sep 2004 12:25:04 -0400 Received: from natsmtp00.rzone.de ([81.169.145.165]:26825 "EHLO natsmtp00.rzone.de") by vger.kernel.org with ESMTP id S267810AbUIUQY4 (ORCPT ); Tue, 21 Sep 2004 12:24:56 -0400 Date: Tue, 21 Sep 2004 18:16:50 +0200 From: Dominik Brodowski To: Con Kolivas Cc: linux-kernel@vger.kernel.org, akpm@osdl.org Subject: Re: Add on-demand cpu-freq governor as default option Message-ID: <20040921161650.GA8119@dominikbrodowski.de> Mail-Followup-To: Dominik Brodowski , Con Kolivas , linux-kernel@vger.kernel.org, akpm@osdl.org References: <20040920170216.GA7952@dominikbrodowski.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1911 Lines: 40 Hi, On Tue, Sep 21, 2004 at 08:43:09AM +1000, Con Kolivas wrote: > 1. Would it be inappropriate to make it drop back to a different governor > so that it can be selected? This would involve major changes to the cpufreq core, and it wouldn't make it easier. I'll add it to my TODO list and think about it again once more important issues are adressed. Agreed? > 2. Can cpu throttling be incorporated into this governor as well as a > secondary mechanism for the lowest cpu frequency and as a primary > mechanism for those cpus that don't support cpufreq? a) it hasn't to do anything with the _governor_. The governor works with whatever method is offered to him, may it be frequency scaling or throttling. Actually, some CPUfreq drivers actually only do throttling, and you can use ondemand for them [if their latency values are set correctly, that is]. b) on-demand throttling is useless. Throttling sets the CPU to the same internal power state as the ACPI idle state C2 does [and C2 has quite the same energy consumption as C1, actually...], so lowering the time spent idling and increasing throttling doesn't save energy, while lowering idling and increasing frequency scaling does save much energy. c) As throttling does make sense for thermal management and certain energy consumption requirements [e.g. the battery isn't strong enough for the CPU running at 100%], adapting the CPUfreq core to support loading one frequency scaling and one frequency throttling driver at the same time is something I have in my TODO list as well. Nonetheless, it will not be made available for "on-demand" throttling, unless I'm convinced otherwise. Thanks, Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/