Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Wed, Mar 8, 2017 at 12:15 PM, Viresh Kumar wrote: > On 08-03-17, 11:50, Rafael J. Wysocki wrote: >> So overall, maybe you can move the flags check to >> sugov_update_shared(), so that you don't need to pass flags to >> sugov_next_freq_shared(), and then do what you did

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Wed, Mar 8, 2017 at 12:15 PM, Viresh Kumar wrote: > On 08-03-17, 11:50, Rafael J. Wysocki wrote: >> So overall, maybe you can move the flags check to >> sugov_update_shared(), so that you don't need to pass flags to >> sugov_next_freq_shared(), and then do what you did to util and max. > >

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 08-03-17, 11:50, Rafael J. Wysocki wrote: > So overall, maybe you can move the flags check to > sugov_update_shared(), so that you don't need to pass flags to > sugov_next_freq_shared(), and then do what you did to util and max. Just to confirm, below is what you are suggesting ?

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 08-03-17, 11:50, Rafael J. Wysocki wrote: > So overall, maybe you can move the flags check to > sugov_update_shared(), so that you don't need to pass flags to > sugov_next_freq_shared(), and then do what you did to util and max. Just to confirm, below is what you are suggesting ?

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Wed, Mar 8, 2017 at 5:18 AM, Viresh Kumar wrote: > On 07-03-17, 14:19, Rafael J. Wysocki wrote: >> On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar >> wrote: >> > Why do you think so? I thought all CPU in the policy can have the RT/DL >> > flag

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Wed, Mar 8, 2017 at 5:18 AM, Viresh Kumar wrote: > On 07-03-17, 14:19, Rafael J. Wysocki wrote: >> On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar >> wrote: >> > Why do you think so? I thought all CPU in the policy can have the RT/DL >> > flag set >> > and the probability of all of them is

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 07-03-17, 14:19, Rafael J. Wysocki wrote: > On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar wrote: > > Why do you think so? I thought all CPU in the policy can have the RT/DL > > flag set > > and the probability of all of them is just the same. > > Well, yes, but if

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 07-03-17, 14:19, Rafael J. Wysocki wrote: > On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar wrote: > > Why do you think so? I thought all CPU in the policy can have the RT/DL > > flag set > > and the probability of all of them is just the same. > > Well, yes, but if the current CPU has that

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar wrote: > On 06-03-17, 13:24, Rafael J. Wysocki wrote: >> On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: >> > On 04-03-17, 01:11, Rafael J. Wysocki wrote: >> >> So one idea is that if

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar wrote: > On 06-03-17, 13:24, Rafael J. Wysocki wrote: >> On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: >> > On 04-03-17, 01:11, Rafael J. Wysocki wrote: >> >> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even >> >> need

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 06-03-17, 13:24, Rafael J. Wysocki wrote: > On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: > > On 04-03-17, 01:11, Rafael J. Wysocki wrote: > >> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even > >> need to start the loop which is quite a

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 06-03-17, 13:24, Rafael J. Wysocki wrote: > On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: > > On 04-03-17, 01:11, Rafael J. Wysocki wrote: > >> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even > >> need to start the loop which is quite a cost to simply notice

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: > On 04-03-17, 01:11, Rafael J. Wysocki wrote: >> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even >> need to start the loop which is quite a cost to simply notice that there's >> nothing to do.

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Mon, Mar 6, 2017 at 5:45 AM, Viresh Kumar wrote: > On 04-03-17, 01:11, Rafael J. Wysocki wrote: >> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even >> need to start the loop which is quite a cost to simply notice that there's >> nothing to do. > > Hmm. Isn't the

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 04-03-17, 01:11, Rafael J. Wysocki wrote: > So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even > need to start the loop which is quite a cost to simply notice that there's > nothing to do. Hmm. Isn't the probability of this flag being set, same for all CPUs in the

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On 04-03-17, 01:11, Rafael J. Wysocki wrote: > So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even > need to start the loop which is quite a cost to simply notice that there's > nothing to do. Hmm. Isn't the probability of this flag being set, same for all CPUs in the

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Saturday, March 04, 2017 01:03:17 AM Rafael J. Wysocki wrote: > On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > > The same code is present both within and outside the loop and it doesn't > > look like it provides any additional benefit. > > Well, not quite. This is on purpose. >

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Saturday, March 04, 2017 01:03:17 AM Rafael J. Wysocki wrote: > On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > > The same code is present both within and outside the loop and it doesn't > > look like it provides any additional benefit. > > Well, not quite. This is on purpose. >

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > The same code is present both within and outside the loop and it doesn't > look like it provides any additional benefit. Well, not quite. This is on purpose. Note the "if (j == smp_processor_id())" condition within the loop and think

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > The same code is present both within and outside the loop and it doesn't > look like it provides any additional benefit. Well, not quite. This is on purpose. Note the "if (j == smp_processor_id())" condition within the loop and think

[PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

The same code is present both within and outside the loop and it doesn't look like it provides any additional benefit. Remove the special handling of sg_cpu and let it happen within the loop. With this change we will do two extra comparisons for the sg_cpu in the loop, but the loop will do one

[PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

The same code is present both within and outside the loop and it doesn't look like it provides any additional benefit. Remove the special handling of sg_cpu and let it happen within the loop. With this change we will do two extra comparisons for the sg_cpu in the loop, but the loop will do one