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.
>
>
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 i
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 w
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
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 s
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 w
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
On Wednesday, July 26, 2017 11:59:12 AM Viresh Kumar wrote:
> On 24-07-17, 15:47, Peter Zijlstra wrote:
> > I said nothing about the shared locking. That is indeed required. All I
> > said is that those two tests you add could be left out.
>
> I was right, I didn't understood your comment at all :
On Wed, Jul 26, 2017 at 11:59:12AM +0530, Viresh Kumar wrote:
> On 24-07-17, 15:47, Peter Zijlstra wrote:
> > I said nothing about the shared locking. That is indeed required. All I
> > said is that those two tests you add could be left out.
>
> I was right, I didn't understood your comment at all
On 24-07-17, 15:47, Peter Zijlstra wrote:
> I said nothing about the shared locking. That is indeed required. All I
> said is that those two tests you add could be left out.
I was right, I didn't understood your comment at all :(
> > > That would then continue to process the iowait and other acco
On Mon, Jul 24, 2017 at 04:31:22PM +0530, Viresh Kumar wrote:
> On 21-07-17, 15:03, Peter Zijlstra wrote:
> > On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote:
> > > diff --git a/kernel/sched/cpufreq_schedutil.c
> > > b/kernel/sched/cpufreq_schedutil.c
> > > index 29a397067ffa..ed9c58
On 21-07-17, 15:03, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote:
> > @@ -42,6 +42,7 @@ void cpufreq_add_update_util_hook(int cpu, struct
> > update_util_data *data,
> > return;
> >
> > data->func = func;
> > + data->cpu = cpu;
> > r
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
We do not call cpufreq callbacks from scheduler core for remote
(non-local) CPUs currently. But there are cases where such remote
callbacks are useful, specially in the case of shared cpufreq policies.
This patch updates the scheduler core to call the cpufreq callbacks for
remote CPUs as well.
Fo
14 matches
Mail list logo
