Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1697560
| From | Saravana Kannan <skannan@codeaurora.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks |
| Date | 2017-07-26 23:10 +0200 |
| Message-ID | <u7BJ8-5vg-19@gated-at.bofh.it> (permalink) |
| References | <u2G6J-2a4-3@gated-at.bofh.it> <u2G6K-2a4-17@gated-at.bofh.it> <u5FQR-5ft-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/21/2017 06:03 AM, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote: >> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c >> index 47e24b5384b3..606b1a37a1af 100644 >> --- a/drivers/cpufreq/cpufreq_governor.c >> +++ b/drivers/cpufreq/cpufreq_governor.c >> @@ -275,6 +275,10 @@ static void dbs_update_util_handler(struct update_util_data *data, u64 time, >> struct policy_dbs_info *policy_dbs = cdbs->policy_dbs; >> u64 delta_ns, lst; >> >> + /* Don't allow remote callbacks */ >> + if (smp_processor_id() != data->cpu) >> + return; >> + > > The alternative is using some of that policy_dbs->policy->*cpus crud I > suppose, because: No, the alternative is to pass it on to the CPU freq driver and let it decide what it wants to do. That's the whole point if having a CPU freq driver -- so that the generic code doesn't need to care about HW specific details. Which is the point I was making in an earlier email to Viresh's patch -- we shouldn't be doing any CPU check for the call backs at the scheduler or ever governor level. That would simplify this whole thing by deleting a bunch of code. And having much simpler checks in those drivers that actually have to deal with their HW specific details. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Peter Zijlstra <peterz@infradead.org> - 2017-07-21 15:10 +0200
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-24 13:10 +0200
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Peter Zijlstra <peterz@infradead.org> - 2017-07-24 15:50 +0200
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 08:30 +0200
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Peter Zijlstra <peterz@infradead.org> - 2017-07-26 10:20 +0200
Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-26 19:40 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Saravana Kannan <skannan@codeaurora.org> - 2017-07-26 23:10 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 05:40 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Saravana Kannan <skannan@codeaurora.org> - 2017-07-27 22:00 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-28 06:40 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-28 08:10 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Saravana Kannan <skannan@codeaurora.org> - 2017-07-28 23:10 +0200
Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-31 06:00 +0200
csiph-web