From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
Linux PM <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Steve Muckle <smuckle.linux@gmail.com>,
Juri Lelli <juri.lelli@arm.com>,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
eas-dev@lists.linaro.org
Subject: Re: [RFC 5/9] sched: cpufreq: remove smp_processor_id() in remote paths
Date: Wed, 12 Apr 2017 19:56:28 +0530 [thread overview]
Message-ID: <20170412142628.GH5910@vireshk-i7> (raw)
In-Reply-To: <CAJZ5v0iQ4X=Vt54EvJce9R9rPhtVqvznte8=HoQ_UOAZ1fQj2g@mail.gmail.com>
On 11-04-17, 16:00, Rafael J. Wysocki wrote:
> On Tue, Apr 11, 2017 at 12:35 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 29-03-17, 23:28, Rafael J. Wysocki wrote:
> >> On Thursday, March 09, 2017 05:15:15 PM Viresh Kumar wrote:
> >> > @@ -216,7 +216,7 @@ static void sugov_update_single(struct update_util_data *hook, u64 time,
> >> > if (flags & SCHED_CPUFREQ_RT_DL) {
> >> > next_f = policy->cpuinfo.max_freq;
> >> > } else {
> >> > - sugov_get_util(&util, &max);
> >> > + sugov_get_util(&util, &max, hook->cpu);
> >>
> >> Why is this not racy?
> >
> > Why would reading the utilization values be racy? The only dynamic value here is
> > "util_avg" and I am not sure if reading it is racy.
> >
> > But, this whole routine has races which I ignored as we may end up updating
> > frequency simultaneously from two threads.
>
> Those races aren't there if we don't update cross-CPU, which is my point. :-)
Of course. There are no races without this series.
> >> > sugov_iowait_boost(sg_cpu, &util, &max);
> >> > next_f = get_next_freq(sg_policy, util, max);
> >> > }
> >> > @@ -272,7 +272,7 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time,
> >> > unsigned long util, max;
> >> > unsigned int next_f;
> >> >
> >> > - sugov_get_util(&util, &max);
> >> > + sugov_get_util(&util, &max, hook->cpu);
> >> >
> >>
> >> And here?
> >>
> >> > raw_spin_lock(&sg_policy->update_lock);
> >
> > The lock prevents the same here though.
> >
> > So, if we are going to use this series, then we can use the same update-lock in
> > case of single cpu per policies as well.
>
> No, we can't.
>
> The lock is unavoidable in the mulit-CPU policies case, but there's no
> way I will agree on using a lock in the single-CPU case.
How do you suggest to avoid the locking here then ? Some atomic
variable read/write as done in cpufreq_governor.c ?
--
viresh
next prev parent reply other threads:[~2017-04-12 14:26 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 11:45 [RFC 0/9] cpufreq: schedutil: Allow remote wakeups Viresh Kumar
2017-03-09 11:45 ` [RFC 1/9] sched: cpufreq: add cpu to update_util_data Viresh Kumar
2017-03-29 21:18 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 2/9] irq_work: add irq_work_queue_on for !CONFIG_SMP Viresh Kumar
2017-03-29 21:20 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 3/9] cpufreq: Add dvfs_possible_from_any_cpu policy flag Viresh Kumar
2017-03-29 21:22 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 4/9] sched: cpufreq: extend irq work to support fast switches Viresh Kumar
2017-03-29 21:25 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 5/9] sched: cpufreq: remove smp_processor_id() in remote paths Viresh Kumar
2017-03-29 21:28 ` Rafael J. Wysocki
2017-04-11 10:35 ` Viresh Kumar
2017-04-11 14:00 ` Rafael J. Wysocki
2017-04-12 14:26 ` Viresh Kumar [this message]
2017-04-12 22:53 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 6/9] sched: cpufreq: detect, process remote callbacks Viresh Kumar
2017-03-29 21:58 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 7/9] cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs Viresh Kumar
2017-03-29 22:14 ` Rafael J. Wysocki
2017-04-11 11:06 ` Viresh Kumar
2017-03-09 11:45 ` [RFC 8/9] intel_pstate: ignore " Viresh Kumar
2017-03-29 22:15 ` Rafael J. Wysocki
2017-03-09 11:45 ` [RFC 9/9] sched: cpufreq: enable remote sched cpufreq callbacks Viresh Kumar
2017-03-15 11:45 ` [RFC 0/9] cpufreq: schedutil: Allow remote wakeups Rafael J. Wysocki
2017-03-16 3:09 ` Viresh Kumar
2017-03-16 10:04 ` Rafael J. Wysocki
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=20170412142628.GH5910@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=Morten.Rasmussen@arm.com \
--cc=eas-dev@lists.linaro.org \
--cc=juri.lelli@arm.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=smuckle.linux@gmail.com \
--cc=vincent.guittot@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.