LKML Archive on
help / color / mirror / Atom feed
From: Venkatesh Pallipadi <>
To: linux-kernel <>,, Andrew Morton <>,
	Dave Jones <>
Cc:, Len Brown <>
Subject: Re: [PATCH 2.6.18-rc6-mm1 0/2] cpufreq: make it harder for cpu to leave "hot" mode
Date: Tue, 12 Sep 2006 13:05:00 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>; from on Mon, Sep 11, 2006 at 11:29:24PM -0400

On Mon, Sep 11, 2006 at 11:29:24PM -0400, Nick Orlov wrote:
> Andrew,
> I was playing with ondemand cpufreq governor (gotta save on electricity
> bills one day :) ) and I've noticed that gameplay become somewhat sluggish.
> Especially noticeble in something cpu-power demanding, like quake4.
> Quick look at stats/trans_table confirmed that CPU goes out of "hot" mode
> way too often.

ondemand governor adjusts the sampling rate depending on frequency transition
latency of CPU. Say the frequency transition latency for a CPU is 100uS,
it will sample atmost once every 100mS and by that rule performance
impact of the transitions alone should not be more than 0.1 %.

There will be performance impact however, if it chooses a lower frequency and
CPU becomes 100% busy immediately after that. That will be a issue with
any history based speculation. Once can have a workload that will fool the
algorithm to take wrong decision every time.

Having said that, I am curious to see actual numbers that you are seeing in
different cases:
- The transition latency for frequency switching on your CPU.
- Default ondemand sampling rate on your system.
- Different frequencies supported on your system.
- I guess you have a dual core CPU. Whether they are changing frequencies 
correctly at the same time or changing frequency of one CPU is wrongly 
affecting the other CPU.
- trans table for the load with and without mm changes for ondemand.

> To make long story short - reverting -mm changes for cpufreq_ondemand.c
> helps a _LOT_.  I'm not sure if it is something powersave_bias related or
> (most probably) due to alignment of "next do_dbs_timer() fire time" which
> could make "collect stats" window too short and introduce significant errors.
> Have not specifically checked ...

The change in mm should not change anything related to sampling interval. If
it is indeed doing something like that, then it will be a bug. Can you please
check sampling_rate (under sys cpufreq/ondemand) with and without mm changes.
That will tell how frequently kernel is checking the stats.

> After thinking about the issue for a while I come up with the following tweaks:
> First of all I made hysteresis little bit wider (20% instead of 10).

This is a heuristic and this change will make ondemand more conservative
in some cases and ondemand will not be able to reduce frequency and
hence end up consuming more power.

If this is really needed, then it sould be a tunable to ondemand rather than a
new absolute value. As this is only changing the next frequency to be one that
keeps CPU 60% busy than 70% busy, and these two frequencies must be close
to each other anyway, I dont think this can cause performance degradation
due to wrong/low freq.

> Another idea was to increase "sampling period" once cpu is in "hot" mode.
> Second part also have benefits of reducing the load on already overloaded cpu.
> Plus it's damn trivial. To simplify further testing I have exposed
> "sampling_rate_hot" parameter through sysfs. Setting it to sampling_rate * 10
> works for me very well. Now I do not have to switch governor to "performance"
> during game sessions.

Again, I dont think frequent checking in ondemand is a bad thing as
it allows ondemand to be aggressive and save as much power and also
have quick response time for increased load. If we really have a issue
with sampling rate, it is possibly due to wrong transition latency
advertised by the driver and we are wasting more time doing
transitions than ondemand thinks it is spending.

If the sampling rate is indeed high for your system/workload, you should be
able to get the same result by just increasing the sampling_rate in 
sysfs cpufreq/ondemand than having a new tunable.


  parent reply	other threads:[~2006-09-12 20:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-12  3:29 Nick Orlov
2006-09-12  3:30 ` [PATCH 2.6.18-rc6-mm1 1/2] " Nick Orlov
2006-09-12  3:31 ` [PATCH 2.6.18-rc6-mm1 2/2] " Nick Orlov
2006-09-12 20:05 ` Venkatesh Pallipadi [this message]
2006-09-14  4:48 ` [PATCH 2.6.18-rc6-mm1 0/2] " Nick Orlov
2006-09-14 21:38 ` Andrew Morton
2006-09-16  0:32 Pallipadi, Venkatesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2.6.18-rc6-mm1 0/2] cpufreq: make it harder for cpu to leave "hot" mode' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).