Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1611419 > unrolled thread

Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-29 00:30 +0200
    Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE  enter Patrick Bellasi <patrick.bellasi@arm.com> - 2017-04-07 17:10 +0200

#1611419 — Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On Thursday, March 02, 2017 03:45:02 PM Patrick Bellasi wrote:
> Currently, sg_cpu's flags are set to the value defined by the last call of
> the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes
> this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set.
> 
> When multiple CPU shares the same frequency domain it might happen that a
> CPU which executed an RT task, right before entering IDLE, has one of the
> SCHED_CPUFREQ_RT_DL flags set, permanently, until it exits IDLE.

But if it is idle, it won't be taken into account by sugov_next_freq_shared(), will it?

Thanks,
Rafael

[toc] | [next] | [standalone]

#1618883 — Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 29-Mar 00:18, Rafael J. Wysocki wrote:
> On Thursday, March 02, 2017 03:45:02 PM Patrick Bellasi wrote:
> > Currently, sg_cpu's flags are set to the value defined by the last call of
> > the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes
> > this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set.
> > 
> > When multiple CPU shares the same frequency domain it might happen that a
> > CPU which executed an RT task, right before entering IDLE, has one of the
> > SCHED_CPUFREQ_RT_DL flags set, permanently, until it exits IDLE.
> 
> But if it is idle, it won't be taken into account by sugov_next_freq_shared(), will it?

Yes, but:

1) This kind of "useless RT requests" are ignored only if more then
   TICK_NSEC have elapsed since the last update.

2) The proposed patch, apart from resetting the flags, it also bails
   out without potentially triggering an already too late switch to MAX,
   which starts also a new throttling interval.

3) By resetting the flags we keep the internal state machine more
   consistent with what the scheduler knows, i.e. we are now idle.

Considering overall these three points, IMO this small patch makes the
schedutil machinery a bit more predictable.
 
> Thanks,
> Rafael

Cheers Patrick

-- 
#include <best/regards.h>

Patrick Bellasi

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web