public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Dominik Brodowski <linux@dominikbrodowski.net>
To: Youquan Song <youquan.song@intel.com>
Cc: davej@redhat.com, cpufreq@vger.kernel.org, venki@google.com,
	arjan@linux.intel.com, lenb@kernel.org,
	suresh.b.siddha@intel.com, kent.liu@intel.com,
	chaohong.guo@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org,
	Youquan Song <youquan.song@linux.intel.com>
Subject: Re: [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency
Date: Thu, 23 Dec 2010 12:00:20 +0100	[thread overview]
Message-ID: <20101223110020.GC18363@comet.dominikbrodowski.net> (raw)
In-Reply-To: <1293085424-18212-1-git-send-email-youquan.song@intel.com>

Hey,

On Thu, Dec 23, 2010 at 02:23:38PM +0800, Youquan Song wrote:
> Running a well-known power performance benchmark, current ondemand governor is
> not power efficiency. Even when workload is at 10%~20% of full capability, the
> CPU will also run much of time at highest frequency. In fact, in this situation,
> the lowest frequency often can meet user requirement. When running this
> benchmark on turbo mode enable machine, I compare the result of different
> governors, the results of ondemand and performance governors are the closest.
> There is no much power saving between ondemand and performance governor. If we
> can ignore the little power saving, the perfomance governor even better than 
> ondemand governor, at leaset for better performance. 
> 
> One potential reason for ondemand governor is not power efficiency is that
> ondemand governor decide the next target frequency by instant requirement during
> sampling interval (10ms or possible a little longer for deferrable timer in idle
> tickless). The instant requirement can response quickly to workload change, but
> it does not usually reflect workload real CPU usage requirement in a small 
> longer time and it possibly causes frequently change between highest and lowest
> frequency.     
> 
> This patchset add a sampling window for percpu ondemand thread. Each sampling
> window with max 150 record items which slide every sampling interval and use to
> track the workload requirement during latest sampling window timeframe. 
> The average of workload during latest sample windows will be used to decide next
> target frequency. The sampling window targets to be more truly reflects workload
> requirement of CPU usage. 
> 
> The sampling window size can be set by user and default max sampling window
> is one second. When it is set to default sampling rate, the sampling window will
> roll back to original behaviour.
> 
> The sampling window size also can be dynamicly changed in according to current
> system workload busy situation. The more idle, the smaller sampling window; the
> more busy, the larger sampling window. It will increase the respnose speed by
> decrease sampling window, while it will keep CPU working at high speed when busy
> by increase sampling window and also avoid unefficiently dangle between highest
> and lowest frequency in original ondemand.
> 
> We set to up_threshold to 80 and down_differential to 20, so when workload reach
>  80% of current frequency, it will increase to highest frequency. When workload
> decrease to below (up_threshold - down_differential)60% of current frequency
> capability, it will decrease the frequency, which ensure that CPU work above 60%
> of its current capability, otherwise lowest frequency will be used. 

Interesting approach, but seems to be quite different from what "ondemand"
does at the moment. And, as David Niemi pointed out, it seems to be more
Intel-specific. Therefore, what do you think about adding this different
algorithm as a different governor, and keep the "ondemand" algorithm more or
less as it is?

Best,
	Dominik

  parent reply	other threads:[~2010-12-23 11:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-23  6:23 [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency Youquan Song
2010-12-23  6:23 ` [PATCH 1/6] cpufreq: Add sampling window for ondemand governor Youquan Song
2010-12-23  6:23   ` [PATCH 2/6] cpufreq: Add sampling_window tunable Youquan Song
2010-12-23  6:23     ` [PATCH 3/6] cpufreq: Add roll back non-sampling_window Youquan Song
2010-12-23  6:23       ` [PATCH 4/6] cpufreq: Add dynamic sampling window tunable Youquan Song
2010-12-23  6:23         ` [PATCH 5/6] cpufreq: Add down_differential tunable Youquan Song
2010-12-23  6:23           ` [PATCH 6/6] cpufreq: Evaluate P1 before enter turbo mode Youquan Song
2010-12-23 10:57             ` Dominik Brodowski
2010-12-23 14:38               ` Matthew Garrett
2010-12-23 18:13                 ` Venkatesh Pallipadi
2010-12-23 20:48                   ` Dominik Brodowski
2010-12-23 11:00 ` Dominik Brodowski [this message]
2010-12-23 17:34   ` [PATCH 0/6] cpufreq: Add sampling window to enhance ondemand governor power efficiency Dave Jones
     [not found]   ` <20101223173402.GA3821@redhat.com>
2010-12-23 20:51     ` Dominik Brodowski
     [not found]     ` <20101223205148.GB6441@comet.dominikbrodowski.net>
2010-12-25  4:24       ` James Cloos
2010-12-24  3:06   ` Youquan Song
2010-12-23 14:42 ` Matthew Garrett
2010-12-24  4:28   ` Youquan Song
     [not found] ` <BBBDBC5FD59D92459FAEF7D8EA3361C402A1A424@DUL1WNEXMB05.vcorp.ad.vrsn.com>
2010-12-23 23:26   ` Youquan Song
  -- strict thread matches above, loose matches on Subject: below --
2010-12-23  6:17 Youquan Song

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20101223110020.GC18363@comet.dominikbrodowski.net \
    --to=linux@dominikbrodowski.net \
    --cc=arjan@linux.intel.com \
    --cc=chaohong.guo@intel.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=kent.liu@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=venki@google.com \
    --cc=youquan.song@intel.com \
    --cc=youquan.song@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox