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.
>
> Just
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 ?
-
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 jus
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 fla
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 t
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 that
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 probabi
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
policy?
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.
>
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
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 les
11 matches
Mail list logo