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

On Wednesday, February 22, 2012, MyungJoo Ham wrote:
> 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;
> +

What about doing

			mutex_unlock(&dbs_info->timer_mutex);
			continue;

here instead of the jump?


> +		timer = &dbs_info->work.timer;
> +		appointed_at = timer->expires;
> +

I would do

		next_sampling = jiffies + usecs_to_jiffies(new_rate);

and compare that with timer->expires.  Then, the if () below would look better.
Or perhaps use new_rate_jiffies = usecs_to_jiffies(new_rate) and use that here
and below?

> +		if (time_before(jiffies + usecs_to_jiffies(new_rate),
> +				appointed_at)) {
> +
> +			mutex_unlock(&dbs_info->timer_mutex);

I'm not sure if this isn't going to be racy.  Have you verified that?

> +			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;
>  }

Thanks,
Rafael

  reply	other threads:[~2012-02-25 23:55 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       ` [RFC PATCH 1/2] CPUfreq ondemand: update sampling rate without waiting for next sampling MyungJoo Ham
2012-02-25 23:59         ` Rafael J. Wysocki [this message]
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=201202260059.02347.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --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=myungjoo.ham@samsung.com \
    --cc=pavel@ucw.cz \
    /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).