linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: MyungJoo Ham <myungjoo.ham@samsung.com>
To: cpufreq@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org
Cc: Dave Jones <davej@redhat.com>, Len Brown <len.brown@intel.com>,
	Pavel Machek <pavel@ucw.cz>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Kevin Hilman <khilman@ti.com>, Jean Pihet <j-pihet@ti.com>,
	markgross <markgross@thegnar.org>,
	kyungmin.park@samsung.com, myungjoo.ham@gmail.com
Subject: [RFC PATCH 1/2] CPUfreq ondemand: update sampling rate without waiting for next sampling
Date: Wed, 22 Feb 2012 17:03:34 +0900	[thread overview]
Message-ID: <1329897815-15871-2-git-send-email-myungjoo.ham@samsung.com> (raw)
In-Reply-To: <1329897815-15871-1-git-send-email-myungjoo.ham@samsung.com>

When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
 drivers/cpufreq/cpufreq_ondemand.c |   58 +++++++++++++++++++++++++++++++++++-
 1 files changed, 57 insertions(+), 1 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index c3e0652..2d66649 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -257,6 +257,62 @@ show_one(sampling_down_factor, sampling_down_factor);
 show_one(ignore_nice_load, ignore_nice);
 show_one(powersave_bias, powersave_bias);
 
+/**
+ * update_sampling_rate - update sampling rate effective immediately if needed.
+ * @new_rate: new sampling rate
+ *
+ * If new rate is smaller than the old, simply updaing
+ * dbs_tuners_int.sampling_rate might not be appropriate. For example,
+ * if the original sampling_rate was 1 second and the requested new sampling
+ * rate is 10 ms because the user needs immediate reaction from ondemand
+ * governor, but not sure if higher frequency will be required or not,
+ * then, the governor may change the sampling rate too late; up to 1 second
+ * later. Thus, if we are reducing the sampling rate, we need to make the
+ * new value effective immediately.
+ */
+static void update_sampling_rate(unsigned int new_rate)
+{
+	int cpu;
+
+	dbs_tuners_ins.sampling_rate = new_rate
+				     = max(new_rate, min_sampling_rate);
+
+	for_each_online_cpu(cpu) {
+		struct cpufreq_policy *policy;
+		struct cpu_dbs_info_s *dbs_info;
+		struct timer_list *timer;
+		unsigned long appointed_at;
+
+		policy = cpufreq_cpu_get(cpu);
+		if (!policy)
+			continue;
+		dbs_info = &per_cpu(od_cpu_dbs_info, policy->cpu);
+		cpufreq_cpu_put(policy);
+
+		mutex_lock(&dbs_info->timer_mutex);
+
+		if (!delayed_work_pending(&dbs_info->work))
+			goto next;
+
+		timer = &dbs_info->work.timer;
+		appointed_at = timer->expires;
+
+		if (time_before(jiffies + usecs_to_jiffies(new_rate),
+				appointed_at)) {
+
+			mutex_unlock(&dbs_info->timer_mutex);
+			cancel_delayed_work_sync(&dbs_info->work);
+			mutex_lock(&dbs_info->timer_mutex);
+
+			schedule_delayed_work_on(dbs_info->cpu, &dbs_info->work,
+						 usecs_to_jiffies(new_rate));
+
+		}
+next:
+		mutex_unlock(&dbs_info->timer_mutex);
+	}
+}
+
 static ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
 				   const char *buf, size_t count)
 {
@@ -265,7 +321,7 @@ static ssize_t store_sampling_rate(struct kobject *a, struct attribute *b,
 	ret = sscanf(buf, "%u", &input);
 	if (ret != 1)
 		return -EINVAL;
-	dbs_tuners_ins.sampling_rate = max(input, min_sampling_rate);
+	update_sampling_rate(input);
 	return count;
 }
 
-- 
1.7.4.1


  reply	other threads:[~2012-02-22  8:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-14  2:26 [RFC PATCH] PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency MyungJoo Ham
2012-02-14  5:04 ` MyungJoo Ham
2012-02-25 23:43   ` Rafael J. Wysocki
2012-02-27  6:14     ` MyungJoo Ham
2012-02-27  6:22     ` [PATCH v2] " MyungJoo Ham
2012-02-14 22:11 ` [RFC PATCH] " Rafael J. Wysocki
2012-02-15 10:44   ` MyungJoo Ham
2012-02-22  8:03     ` [RFC PATCH 0/2] CPUFreq / Ondemand update MyungJoo Ham
2012-02-22  8:03       ` MyungJoo Ham [this message]
2012-02-25 23:59         ` [RFC PATCH 1/2] CPUfreq ondemand: update sampling rate without waiting for next sampling Rafael J. Wysocki
2012-02-28  2:19           ` MyungJoo Ham
2012-02-22  8:03       ` [RFC PATCH 2/2] CPUfreq ondemand: handle QoS request on DVFS response latency MyungJoo Ham
2012-02-25 11:30         ` Pavel Machek
2012-02-25 23:47           ` Rafael J. Wysocki
2012-02-28  0:39             ` MyungJoo Ham
2012-02-29  8:54       ` [PATCH v2 0/2] CPUFreq / Ondemand update MyungJoo Ham
2012-02-29  8:54         ` [PATCH v2 1/2] CPUfreq ondemand: update sampling rate without waiting for next sampling MyungJoo Ham
2012-02-29  8:54         ` [PATCH v2 2/2] CPUfreq ondemand: handle QoS request on DVFS response latency MyungJoo Ham
2012-02-25 17:59 ` [RFC PATCH] PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency mark gross

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=1329897815-15871-2-git-send-email-myungjoo.ham@samsung.com \
    --to=myungjoo.ham@samsung.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=j-pihet@ti.com \
    --cc=khilman@ti.com \
    --cc=kyungmin.park@samsung.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=markgross@thegnar.org \
    --cc=myungjoo.ham@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /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;
as well as URLs for NNTP newsgroup(s).