On Thu, Jul 27, 2017 at 12:14 AM, Viresh Kumar wrote:
> On 26-07-17, 23:13, Joel Fernandes (Google) wrote:
>> On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar
>> wrote:
>> > On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
>> >> On Wed, Jul 26,
On Thu, Jul 27, 2017 at 12:14 AM, Viresh Kumar wrote:
> On 26-07-17, 23:13, Joel Fernandes (Google) wrote:
>> On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar
>> wrote:
>> > On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
>> >> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
>> >> wrote:
>> >>
On Wed, Jul 26, 2017 at 02:52:32PM +0530, Viresh Kumar wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 45fcf21ad685..bb834747e49b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,10 +72,15 @@
On Wed, Jul 26, 2017 at 02:52:32PM +0530, Viresh Kumar wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 45fcf21ad685..bb834747e49b 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,10 +72,15 @@
On Thu, Jul 27, 2017 at 12:44:41PM +0530, Viresh Kumar wrote:
> Even that was discussed tomorrow with Peter :)
Just to clarify I don't have a time machine. That discussion was
_yesterday_,... I think :-)
On Thu, Jul 27, 2017 at 12:44:41PM +0530, Viresh Kumar wrote:
> Even that was discussed tomorrow with Peter :)
Just to clarify I don't have a time machine. That discussion was
_yesterday_,... I think :-)
On 26-07-17, 23:13, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar
> wrote:
> > On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> >> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
> >> wrote:
> >> > @@ -221,7
On 26-07-17, 23:13, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar
> wrote:
> > On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> >> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
> >> wrote:
> >> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct
On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar wrote:
> On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
>> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
>> wrote:
>> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct
>> >
On Wed, Jul 26, 2017 at 10:50 PM, Viresh Kumar wrote:
> On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
>> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar
>> wrote:
>> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct
>> > update_util_data *hook, u64 time,
>> >
On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data
> > *hook, u64 time,
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> >
On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data
> > *hook, u64 time,
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > sg_cpu->last_update
Hi Viresh,
On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> 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.
Hi Viresh,
On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar wrote:
> 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
On 26-07-17, 19:42, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:
> > + /* Don't allow remote callbacks */
> > + if (smp_processor_id() != data->cpu)
> > + return;
>
> You can do this check against cpu->cpu, however.
>
> > + /* Don't
On 26-07-17, 19:42, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:
> > + /* Don't allow remote callbacks */
> > + if (smp_processor_id() != data->cpu)
> > + return;
>
> You can do this check against cpu->cpu, however.
>
> > + /* Don't
On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:
> 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
On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:
> 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
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.
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.
20 matches
Mail list logo