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

Groups > linux.kernel > #1682984

Re: [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection triggering points

Show all headers | View raw

On 05-07-17, 09:58, Juri Lelli wrote:
> Since SCHED_DEADLINE doesn't track utilization signal (but reserves a
> fraction of CPU bandwidth to tasks admitted to the system), there is no
> point in evaluating frequency changes during each tick event.
> 
> Move frequency selection triggering points to where running_bw changes.
> 
> Co-authored-by: Claudio Scordino <claudio@evidence.eu.com>
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Luca Abeni <luca.abeni@santannapisa.it>
> ---
> Changes from RFCv0:
> 
>  - modify comment regarding periodic RT updates (Claudio)
> ---
>  kernel/sched/deadline.c |  7 ++++---
>  kernel/sched/sched.h    | 12 ++++++------
>  2 files changed, 10 insertions(+), 9 deletions(-)

Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
  [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
    Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 11:00 +0200
    Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Peter Zijlstra <peterz@infradead.org> - 2017-07-11 18:20 +0200
      Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all  CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-07-11 19:20 +0200
  [RFC PATCH v1 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
    Re: [RFC PATCH v1 7/8] sched/sched.h: move  arch_scale_{freq,cpu}_capacity outside CONFIG_SMP Steven Rostedt <rostedt@goodmis.org> - 2017-07-08 00:10 +0200
  [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
    Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Joel Fernandes <joelaf@google.com> - 2017-07-07 05:30 +0200
    Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 11:00 +0200
      Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Juri Lelli <juri.lelli@arm.com> - 2017-07-07 13:00 +0200
        Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals Joel Fernandes <joelaf@google.com> - 2017-07-10 09:50 +0200
    Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization  signals Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-10 09:10 +0200
  [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection triggering points Juri Lelli <juri.lelli@arm.com> - 2017-07-05 11:10 +0200
    Re: [RFC PATCH v1 2/8] sched/deadline: move cpu frequency selection  triggering points Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-07 09:30 +0200
  Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Steven Rostedt <rostedt@goodmis.org> - 2017-07-06 18:00 +0200
    Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Juri Lelli <juri.lelli@arm.com> - 2017-07-06 18:10 +0200
    Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-07-06 18:20 +0200
  Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-06 23:20 +0200

csiph-web