Subject: Re: [PATCH] cpufreq_ondemand
From: Len Brown <len.brown@intel.com>
To: Andre Eisenbach <int2str@gmail.com>
Cc: Con Kolivas <kernel@kolivas.org>, linux-kernel@vger.kernel.org,
       Alexander Clouter <alex-kernel@digriz.org.uk>,
       "cpufreq@www.linux.org.uk" <cpufreq@www.linux.org.uk>
In-Reply-To: <7f800d9f04101922031be5cfe8@mail.gmail.com>
References: <7f800d9f04101922031be5cfe8@mail.gmail.com>
Content-Type: text/plain
Organization: 
Message-Id: <1098257735.26595.4308.camel@d845pe>
Mime-Version: 1.0
Date: 20 Oct 2004 03:35:35 -0400
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1294
Lines: 30

On Wed, 2004-10-20 at 01:03, Andre Eisenbach wrote:

> ... If the
> speed steps down slowly but shoots up 100% quickly (as it is right
> now), even a small task (like opening a folder, or scrolling down in a
> document) will cause a tiny spike to 100% which takes a while to go
> back down. The result is that the CPU spends most of it's time at 100%
> or calming down. I wrote a small test program on my notebook which
> confirms this.

The question is what POLICY we're trying to implement.  If the goal is
to to be energy efficient while the user notices no performance hit,
then fast-up/slow-down is an EXCELLENT strategy.  But if the goal is to
optimize for power savings at the cost of impacting performance, then
another strategy may work better.

The point is that no strategy will be optimal for all policies.  Linux
needs a global power policy manager that the rest of the system can ask
about the current policy.  This way sub-systems can (automatically)
implement whatever local strategies are consistent with that global
policy.

-Len


-
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/