| Message ID | 4237890.zlzv5C60QP@aspire.rjw.lan (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Tue, May 22, 2018 at 2:22 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Tuesday, May 22, 2018 1:42:05 PM CEST Rafael J. Wysocki wrote: >> On Tue, May 22, 2018 at 1:38 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: >> > On 22-05-18, 13:31, Rafael J. Wysocki wrote: >> >> So below is my (compiled-only) version of the $subject patch, obviously based >> >> on the Joel's work. >> >> >> >> Roughly, what it does is to move the fast_switch_enabled path entirely to >> >> sugov_update_single() and take the spinlock around sugov_update_commit() >> >> in the one-CPU case too. > > [cut] > >> > >> > Why do you assume that fast switch isn't possible in shared policy >> > cases ? It infact is already enabled for few drivers. > > I hope that fast_switch is not used with devfs_possible_from_any_cpu set in the > one-CPU policy case, as that looks racy even without any patching. Which would be the only case in which sugov_update_single() would run on a CPU that is not the target. And running sugov_update_single() concurrently on two different CPUs for the same target is a no-no, as we don't prevent concurrent updates from occurring in that path. Which means that the original patch from Joel will be sufficient as long as we ensure that sugov_update_single() can only run on one CPU at a time.
On Tue, May 22, 2018 at 05:27:11PM +0200, Rafael J. Wysocki wrote: > On Tue, May 22, 2018 at 2:22 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Tuesday, May 22, 2018 1:42:05 PM CEST Rafael J. Wysocki wrote: > >> On Tue, May 22, 2018 at 1:38 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > >> > On 22-05-18, 13:31, Rafael J. Wysocki wrote: > >> >> So below is my (compiled-only) version of the $subject patch, obviously based > >> >> on the Joel's work. > >> >> > >> >> Roughly, what it does is to move the fast_switch_enabled path entirely to > >> >> sugov_update_single() and take the spinlock around sugov_update_commit() > >> >> in the one-CPU case too. > > > > [cut] > > > >> > > >> > Why do you assume that fast switch isn't possible in shared policy > >> > cases ? It infact is already enabled for few drivers. > > > > I hope that fast_switch is not used with devfs_possible_from_any_cpu set in the > > one-CPU policy case, as that looks racy even without any patching. > > Which would be the only case in which sugov_update_single() would run > on a CPU that is not the target. > > And running sugov_update_single() concurrently on two different CPUs > for the same target is a no-no, as we don't prevent concurrent updates > from occurring in that path. > > Which means that the original patch from Joel will be sufficient as > long as we ensure that sugov_update_single() can only run on one CPU > at a time. Since target CPU's runqueue lock is held, I don't see how we can run sugov_update_single concurrently with any other CPU for single policy, so protecting such race shouldn't be necessary. Also the "if (work_in_progress)" check I added to the sugov_update_single doesn't change the behavior of single policy from what it is in mainline since we were doing the same thing in already sugov_should_update_freq. thanks, - Joel
On Tue, May 22, 2018 at 11:41 PM, Joel Fernandes <joel@joelfernandes.org> wrote: > On Tue, May 22, 2018 at 05:27:11PM +0200, Rafael J. Wysocki wrote: >> On Tue, May 22, 2018 at 2:22 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> > On Tuesday, May 22, 2018 1:42:05 PM CEST Rafael J. Wysocki wrote: >> >> On Tue, May 22, 2018 at 1:38 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: >> >> > On 22-05-18, 13:31, Rafael J. Wysocki wrote: >> >> >> So below is my (compiled-only) version of the $subject patch, obviously based >> >> >> on the Joel's work. >> >> >> >> >> >> Roughly, what it does is to move the fast_switch_enabled path entirely to >> >> >> sugov_update_single() and take the spinlock around sugov_update_commit() >> >> >> in the one-CPU case too. >> > >> > [cut] >> > >> >> > >> >> > Why do you assume that fast switch isn't possible in shared policy >> >> > cases ? It infact is already enabled for few drivers. >> > >> > I hope that fast_switch is not used with devfs_possible_from_any_cpu set in the >> > one-CPU policy case, as that looks racy even without any patching. >> >> Which would be the only case in which sugov_update_single() would run >> on a CPU that is not the target. >> >> And running sugov_update_single() concurrently on two different CPUs >> for the same target is a no-no, as we don't prevent concurrent updates >> from occurring in that path. >> >> Which means that the original patch from Joel will be sufficient as >> long as we ensure that sugov_update_single() can only run on one CPU >> at a time. > > Since target CPU's runqueue lock is held, I don't see how we can run > sugov_update_single concurrently with any other CPU for single policy, so > protecting such race shouldn't be necessary. If dvfs_possible_from_any_cpu is set, any CPU can run sugov_update_single(), but the kthread will only run on the target itself. So another CPU running sugov_update_single() for the target may be racing with the target's kthread. > Also the "if (work_in_progress)" check I added to the sugov_update_single > doesn't change the behavior of single policy from what it is in mainline > since we were doing the same thing in already sugov_should_update_freq. No, it doesn't, which doesn't mean that this is all OK. :-)
On Tue, May 22, 2018 at 11:52:46PM +0200, Rafael J. Wysocki wrote: > On Tue, May 22, 2018 at 11:41 PM, Joel Fernandes <joel@joelfernandes.org> wrote: > > On Tue, May 22, 2018 at 05:27:11PM +0200, Rafael J. Wysocki wrote: > >> On Tue, May 22, 2018 at 2:22 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > >> > On Tuesday, May 22, 2018 1:42:05 PM CEST Rafael J. Wysocki wrote: > >> >> On Tue, May 22, 2018 at 1:38 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > >> >> > On 22-05-18, 13:31, Rafael J. Wysocki wrote: > >> >> >> So below is my (compiled-only) version of the $subject patch, obviously based > >> >> >> on the Joel's work. > >> >> >> > >> >> >> Roughly, what it does is to move the fast_switch_enabled path entirely to > >> >> >> sugov_update_single() and take the spinlock around sugov_update_commit() > >> >> >> in the one-CPU case too. > >> > > >> > [cut] > >> > > >> >> > > >> >> > Why do you assume that fast switch isn't possible in shared policy > >> >> > cases ? It infact is already enabled for few drivers. > >> > > >> > I hope that fast_switch is not used with devfs_possible_from_any_cpu set in the > >> > one-CPU policy case, as that looks racy even without any patching. > >> > >> Which would be the only case in which sugov_update_single() would run > >> on a CPU that is not the target. > >> > >> And running sugov_update_single() concurrently on two different CPUs > >> for the same target is a no-no, as we don't prevent concurrent updates > >> from occurring in that path. > >> > >> Which means that the original patch from Joel will be sufficient as > >> long as we ensure that sugov_update_single() can only run on one CPU > >> at a time. > > > > Since target CPU's runqueue lock is held, I don't see how we can run > > sugov_update_single concurrently with any other CPU for single policy, so > > protecting such race shouldn't be necessary. > > If dvfs_possible_from_any_cpu is set, any CPU can run > sugov_update_single(), but the kthread will only run on the target > itself. So another CPU running sugov_update_single() for the target > may be racing with the target's kthread. > Yes, I agree. I thought you meant the case of sugov_update_single running currently with other sugov_update_single. So just to be on the same page, I'll fix the commit log and repost this one as is. And then I'll post the smp_rmb() patch separately to address the memory order issue (which I believe is in mainline as well). Basically I was thinking to address Viresh's issue, there should be an smp_mb() after the next_freq is read, but before the write to work_in_progress. thanks, - Joel
Index: linux-pm/kernel/sched/cpufreq_schedutil.c =================================================================== --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c +++ linux-pm/kernel/sched/cpufreq_schedutil.c @@ -92,9 +92,6 @@ static bool sugov_should_update_freq(str !cpufreq_can_do_remote_dvfs(sg_policy->policy)) return false; - if (sg_policy->work_in_progress) - return false; - if (unlikely(sg_policy->need_freq_update)) return true; @@ -103,25 +100,41 @@ static bool sugov_should_update_freq(str return delta_ns >= sg_policy->freq_update_delay_ns; } -static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, - unsigned int next_freq) +static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 time, + unsigned int next_freq) { - struct cpufreq_policy *policy = sg_policy->policy; - if (sg_policy->next_freq == next_freq) - return; + return false; sg_policy->next_freq = next_freq; sg_policy->last_freq_update_time = time; - if (policy->fast_switch_enabled) { - next_freq = cpufreq_driver_fast_switch(policy, next_freq); - if (!next_freq) - return; + return true; +} - policy->cur = next_freq; - trace_cpu_frequency(next_freq, smp_processor_id()); - } else { +static void sugov_fast_switch(struct sugov_policy *sg_policy, u64 time, + unsigned int next_freq) +{ + struct cpufreq_policy *policy = sg_policy->policy; + + if (!sugov_update_next_freq(sg_policy, time, next_freq)) + return; + + next_freq = cpufreq_driver_fast_switch(policy, next_freq); + if (!next_freq) + return; + + policy->cur = next_freq; + trace_cpu_frequency(next_freq, smp_processor_id()); +} + +static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time, + unsigned int next_freq) +{ + if (!sugov_update_next_freq(sg_policy, time, next_freq)) + return; + + if (!sg_policy->work_in_progress) { sg_policy->work_in_progress = true; irq_work_queue(&sg_policy->irq_work); } @@ -307,7 +320,13 @@ static void sugov_update_single(struct u sg_policy->cached_raw_freq = 0; } - sugov_update_commit(sg_policy, time, next_f); + if (sg_policy->policy->fast_switch_enabled) { + sugov_fast_switch(sg_policy, time, next_f); + } else { + raw_spin_lock(&sg_policy->update_lock); + sugov_update_commit(sg_policy, time, next_f); + raw_spin_unlock(&sg_policy->update_lock); + } } static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time) @@ -367,7 +386,10 @@ sugov_update_shared(struct update_util_d if (sugov_should_update_freq(sg_policy, time)) { next_f = sugov_next_freq_shared(sg_cpu, time); - sugov_update_commit(sg_policy, time, next_f); + if (sg_policy->policy->fast_switch_enabled) + sugov_fast_switch(sg_policy, time, next_f); + else + sugov_update_commit(sg_policy, time, next_f); } raw_spin_unlock(&sg_policy->update_lock); @@ -376,13 +398,18 @@ sugov_update_shared(struct update_util_d static void sugov_work(struct kthread_work *work) { struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work); + unsigned int next_freq; + unsigned long flags; + + raw_spin_lock_irqsave(&sg_policy->update_lock, flags); + next_freq = sg_policy->next_freq; + sg_policy->work_in_progress = false; + raw_spin_unlock_irqrestore(&sg_policy->update_lock, flags); mutex_lock(&sg_policy->work_lock); - __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq, + __cpufreq_driver_target(sg_policy->policy, next_freq, CPUFREQ_RELATION_L); mutex_unlock(&sg_policy->work_lock); - - sg_policy->work_in_progress = false; } static void sugov_irq_work(struct irq_work *irq_work)