Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 28-07-17, 14:05, Saravana Kannan wrote: > 1. I'm not saying that. I'm saying assuming CPUs can change the freq only on > behalf of all the CPUs in the same policy is wrong. Again, the scheduler or > governor shouldn't even be making any of that assumption. That's a CPUfreq > driver problem. >

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 28-07-17, 14:05, Saravana Kannan wrote: > 1. I'm not saying that. I'm saying assuming CPUs can change the freq only on > behalf of all the CPUs in the same policy is wrong. Again, the scheduler or > governor shouldn't even be making any of that assumption. That's a CPUfreq > driver problem. >

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus field

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus field

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 27-07-17, 12:55, Saravana Kannan wrote: > Yes. Simplifying isn't always about number of lines of code. It's also about > abstraction. Having generic scheduler code care about HW details doesn't > seem nice. I can argue that even the policy->cpus field is also hardware specific, isn't it ? And

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 27-07-17, 12:55, Saravana Kannan wrote: > Yes. Simplifying isn't always about number of lines of code. It's also about > abstraction. Having generic scheduler code care about HW details doesn't > seem nice. I can argue that even the policy->cpus field is also hardware specific, isn't it ? And

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On Thu, Jul 27, 2017 at 12:55 PM, Saravana Kannan wrote: > On 07/26/2017 08:30 PM, Viresh Kumar wrote: >> >> On 26-07-17, 14:00, Saravana Kannan wrote: >>> >>> 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On Thu, Jul 27, 2017 at 12:55 PM, Saravana Kannan wrote: > On 07/26/2017 08:30 PM, Viresh Kumar wrote: >> >> On 26-07-17, 14:00, Saravana Kannan wrote: >>> >>> 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/26/2017 08:30 PM, Viresh Kumar wrote: On 26-07-17, 14:00, Saravana Kannan wrote: 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/26/2017 08:30 PM, Viresh Kumar wrote: On 26-07-17, 14:00, Saravana Kannan wrote: 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 26-07-17, 14:00, Saravana Kannan wrote: > 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 26-07-17, 14:00, Saravana Kannan wrote: > 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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

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

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

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