From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
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>, 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 2/2] CPUfreq ondemand: handle QoS request on DVFS response latency
Date: Sun, 26 Feb 2012 00:47:15 +0100 [thread overview]
Message-ID: <201202260047.16127.rjw@sisk.pl> (raw)
In-Reply-To: <20120225113005.GC16932@elf.ucw.cz>
On Saturday, February 25, 2012, Pavel Machek wrote:
> On Wed 2012-02-22 17:03:35, MyungJoo Ham wrote:
> > With QoS class, DVFS_RESPONSE_LATENCY, users (device drivers and
> > userspace processes) may express the desired maximum response latency
> > from DVFS mechanisms such as CPUfreq's ondemand governors. Based on such
> > QoS requests, the ondemand governor may flexibly adjust sampling rate
> > accordingly unless it goes below the min_sampling_rate.
> >
> > The benefit of having DVFS_RESPONSE_LATENCY is to have faster response
> > from user inputs (mouse clicks, keyboard inputs, touchscreen touches,
> > and others) without increasing frequency unconditionally. Because some
> > input events may not require any performance increases, increasing the
> > frequency unconditionally for inputs may simply consume too much energy.
> > Adjusting sampling rate based on user inputs enabled to increase
> > frequency with less latency if it requires and not to increase frequency
> > if it does not require.
> >
> > Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > --
> > This patch depends on the patch
> > "PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency".
> > and the patch
> > "CPUfreq ondemand: update sampling rate without waiting for next
> > sampling"
> > ---
> > drivers/cpufreq/cpufreq_ondemand.c | 108 ++++++++++++++++++++++++++++++++----
> > 1 files changed, 96 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
> > index 2d66649..b9188f1 100644
> > --- a/drivers/cpufreq/cpufreq_ondemand.c
> > +++ b/drivers/cpufreq/cpufreq_ondemand.c
> > @@ -22,6 +22,7 @@
> > #include <linux/tick.h>
> > #include <linux/ktime.h>
> > #include <linux/sched.h>
> > +#include <linux/pm_qos.h>
> >
> > /*
> > * dbs is used in this file as a shortform for demandbased switching
> > @@ -93,6 +94,7 @@ struct cpu_dbs_info_s {
> > * when user is changing the governor or limits.
> > */
> > struct mutex timer_mutex;
> > + bool activated; /* dbs_timer_init is in effect */
> > };
> > static DEFINE_PER_CPU(struct cpu_dbs_info_s, od_cpu_dbs_info);
> >
> > @@ -111,6 +113,8 @@ static struct dbs_tuners {
> > unsigned int sampling_down_factor;
> > unsigned int powersave_bias;
> > unsigned int io_is_busy;
> > + struct notifier_block dvfs_lat_qos_db;
> > + unsigned int dvfs_lat_qos_wants;
> > } dbs_tuners_ins = {
> > .up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
> > .sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
> > @@ -164,6 +168,23 @@ static inline cputime64_t get_cpu_iowait_time(unsigned int cpu, cputime64_t *wal
> > }
> >
> > /*
> > + * Find right sampling rate based on sampling_rate and
> > + * QoS requests on dvfs latency.
> > + */
> > +static unsigned int effective_sampling_rate(void)
> > +{
> > + unsigned int effective;
> > +
> > + if (dbs_tuners_ins.dvfs_lat_qos_wants)
> > + effective = min(dbs_tuners_ins.dvfs_lat_qos_wants,
> > + dbs_tuners_ins.sampling_rate);
> > + else
> > + effective = dbs_tuners_ins.sampling_rate;
> > +
> > + return max(effective, min_sampling_rate);
> > +}
> > +
> > +/*
> > * Find right freq to be set now with powersave_bias on.
> > * Returns the freq_hi to be used right now and will set freq_hi_jiffies,
> > * freq_lo, and freq_lo_jiffies in percpu area for averaging freqs.
> > @@ -207,7 +228,7 @@ static unsigned int powersave_bias_target(struct cpufreq_policy *policy,
> > dbs_info->freq_lo_jiffies = 0;
> > return freq_lo;
> > }
> > - jiffies_total = usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
> > + jiffies_total = usecs_to_jiffies(effective_sampling_rate());
> > jiffies_hi = (freq_avg - freq_lo) * jiffies_total;
> > jiffies_hi += ((freq_hi - freq_lo) / 2);
> > jiffies_hi /= (freq_hi - freq_lo);
> > @@ -259,7 +280,8 @@ show_one(powersave_bias, powersave_bias);
> >
> > /**
> > * update_sampling_rate - update sampling rate effective immediately if needed.
> > - * @new_rate: new sampling rate
> > + * @new_rate: new sampling rate. if it is 0, regard sampling rate is not
> > + * changed and assume that qos request value is changed.
> > *
> > * If new rate is smaller than the old, simply updaing
> > * dbs_tuners_int.sampling_rate might not be appropriate. For example,
> > @@ -273,9 +295,13 @@ show_one(powersave_bias, powersave_bias);
> > static void update_sampling_rate(unsigned int new_rate)
> > {
> > int cpu;
> > + unsigned int effective;
> > +
> > +
> > + if (new_rate)
> > + dbs_tuners_ins.sampling_rate = max(new_rate, min_sampling_rate);
> >
> > - dbs_tuners_ins.sampling_rate = new_rate
> > - = max(new_rate, min_sampling_rate);
> > + effective = effective_sampling_rate();
> >
> > for_each_online_cpu(cpu) {
> > struct cpufreq_policy *policy;
> > @@ -283,21 +309,31 @@ static void update_sampling_rate(unsigned int new_rate)
> > struct timer_list *timer;
> > unsigned long appointed_at;
> >
> > + /*
> > + * mutex_destory(&dbs_info->timer_mutex) should not happen
> > + * in this context.
> > + */
> > + mutex_lock(&dbs_mutex);
> > +
> > policy = cpufreq_cpu_get(cpu);
> > if (!policy)
> > - continue;
> > + goto next;
> > dbs_info = &per_cpu(od_cpu_dbs_info, policy->cpu);
> > cpufreq_cpu_put(policy);
> >
> > + /* timer_mutex destroyed or will be destoyed soon */
> > + if (!dbs_info->activated)
> > + goto next;
> > +
> > mutex_lock(&dbs_info->timer_mutex);
> >
> > if (!delayed_work_pending(&dbs_info->work))
> > - goto next;
> > + goto next_timer_mutex;
> >
> > timer = &dbs_info->work.timer;
> > appointed_at = timer->expires;
> >
> > - if (time_before(jiffies + usecs_to_jiffies(new_rate),
> > + if (time_before(jiffies + usecs_to_jiffies(effective),
> > appointed_at)) {
> >
> > mutex_unlock(&dbs_info->timer_mutex);
> > @@ -305,12 +341,15 @@ static void update_sampling_rate(unsigned int new_rate)
> > mutex_lock(&dbs_info->timer_mutex);
> >
> > schedule_delayed_work_on(dbs_info->cpu, &dbs_info->work,
> > - usecs_to_jiffies(new_rate));
> > + usecs_to_jiffies(effective));
> >
> > }
> > -next:
> > +next_timer_mutex:
> > mutex_unlock(&dbs_info->timer_mutex);
> > +next:
> > + mutex_unlock(&dbs_mutex);
> > }
> > +
> > }
>
> I don't think gotos are helpful here. Can you use normal program
> structure or move it to subroutine...?
I agree with Pavel that gotos don't make that code particularly clear.
Thanks,
Rafael
next prev parent reply other threads:[~2012-02-25 23:43 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
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 [this message]
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=201202260047.16127.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).