Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1347699 > unrolled thread
| Started by | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| First post | 2016-03-02 03:30 +0100 |
| Last post | 2016-03-17 17:10 +0100 |
| Articles | 20 on this page of 138 — 11 participants |
Back to article view | Back to linux.kernel
[PATCH 0/6] cpufreq: schedutil governor "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-02 03:30 +0100
[PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-02 03:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-02 18:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-02 19:00 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-02 23:50 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 13:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-03 13:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-03 17:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 17:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 17:50 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 02:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 18:00 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-03 18:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-03 18:00 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-03 15:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 16:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 17:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 17:50 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-03-03 18:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-03 19:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-03-03 20:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-08 14:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-03 20:00 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-03 14:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Steve Muckle <steve.muckle@linaro.org> - 2016-03-03 21:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-03 21:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Steve Muckle <steve.muckle@linaro.org> - 2016-03-03 22:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-07 03:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-08 12:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 19:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-08 20:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-08 21:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-09 11:20 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-10 00:50 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-10 05:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-10 22:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Michael Turquette <mturquette@baylibre.com> - 2016-03-11 00:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-09 17:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-10 00:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-10 04:50 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 11:10 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Vincent Guittot <vincent.guittot@linaro.org> - 2016-03-10 11:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 11:40 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 12:00 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-10 23:30 +0100
Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-10 09:50 +0100
[PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-04 12:30 +0100
Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 14:20 +0100
Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-04 17:00 +0100
[PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Steve Muckle <steve.muckle@linaro.org> - 2016-03-04 23:20 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 23:40 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 23:50 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-05 00:20 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Steve Muckle <steve.muckle@linaro.org> - 2016-03-05 01:00 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-05 01:20 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Ingo Molnar <mingo@kernel.org> - 2016-03-05 13:00 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-05 17:50 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-06 03:20 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-07 09:10 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-07 14:20 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-07 14:40 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-07 14:50 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-05 00:00 +0100
Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching Steve Muckle <steve.muckle@linaro.org> - 2016-03-05 01:00 +0100
[PATCH v2 0/10] cpufreq: schedutil governor "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
[PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit Peter Zijlstra <peterz@infradead.org> - 2016-03-09 13:50 +0100
Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-09 15:20 +0100
Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit Peter Zijlstra <peterz@infradead.org> - 2016-03-09 16:30 +0100
Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-09 22:40 +0100
Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit Peter Zijlstra <peterz@infradead.org> - 2016-03-10 10:20 +0100
[PATCH v2 5/10] cpufreq: Move governor attribute set headers to cpufreq.h "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 5/10] cpufreq: Move governor attribute set headers to cpufreq.h Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-04 07:00 +0100
[PATCH v2 2/10][Resend] cpufreq: acpi-cpufreq: Make read and write operations more efficient "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
[PATCH v2 3/10] cpufreq: governor: New data type for management part of dbs_data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 3/10] cpufreq: governor: New data type for management part of dbs_data Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-04 07:00 +0100
[PATCH v2 7/10] cpufreq: Rework the scheduler hooks for triggering updates "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
[PATCH v2 4/10] cpufreq: governor: Move abstract gov_attr_set code to seperate file "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 4/10] cpufreq: governor: Move abstract gov_attr_set code to seperate file Viresh Kumar <viresh.kumar@linaro.org> - 2016-03-04 07:00 +0100
[PATCH v2 8/10] cpufreq: Move scheduler-related code to the sched directory "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
[PATCH v2 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 04:40 +0100
Re: [PATCH v2 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() Juri Lelli <juri.lelli@arm.com> - 2016-03-04 11:50 +0100
Re: [PATCH v2 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 14:00 +0100
[PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-04 14:30 +0100
Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() Steve Muckle <steve.muckle@linaro.org> - 2016-03-04 22:30 +0100
Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 22:30 +0100
Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-04 22:40 +0100
[PATCH v3 5/7] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 3/7][Resend] cpufreq: governor: New data type for management part of dbs_data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 6/7] cpufreq: sched: Re-introduce cpufreq_update_util() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 4/7][Resend] cpufreq: governor: Move abstract gov_attr_set code to seperate file "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 0/7] cpufreq: schedutil governor "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 1/7][Resend] cpufreq: Rework the scheduler hooks for triggering updates "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
Re: [PATCH v3 1/7][Resend] cpufreq: Rework the scheduler hooks for triggering updates Peter Zijlstra <peterz@infradead.org> - 2016-03-09 14:50 +0100
Re: [PATCH v3 1/7][Resend] cpufreq: Rework the scheduler hooks for triggering updates "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-09 15:10 +0100
[PATCH v3 2/7][Resend] cpufreq: Move scheduler-related code to the sched directory "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v3 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-08 04:00 +0100
[PATCH v4 2/7] cpufreq: governor: New data type for management part of dbs_data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
[PATCH v4 1/7] cpufreq: sched: Helpers to add and remove update_util hooks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
[PATCH v4 4/7] cpufreq: Move governor attribute set headers to cpufreq.h "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
[PATCH v4 0/7] cpufreq: schedutil governor "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
[PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 18:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:50 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 18:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 19:00 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:50 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 19:00 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 23:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 19:20 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 22:40 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-16 23:50 +0100
Re: [PATCH v4 7/7] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-17 00:00 +0100
[PATCH v4 3/7] cpufreq: governor: Move abstract gov_attr_set code to seperate file "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
[PATCH v4 6/7] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
Re: [PATCH v4 6/7] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-16 16:40 +0100
Re: [PATCH v4 6/7] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 18:00 +0100
Re: [PATCH v4 6/7] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-16 16:50 +0100
Re: [PATCH v4 6/7] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 18:00 +0100
[PATCH v4 5/7] cpufreq: Move governor symbols to cpufreq.h "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-16 16:10 +0100
Re: [PATCH v4 0/7] cpufreq: schedutil governor Peter Zijlstra <peterz@infradead.org> - 2016-03-16 16:30 +0100
Re: [PATCH v4 0/7] cpufreq: schedutil governor "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-16 17:30 +0100
[PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-17 01:00 +0100
Re: [PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching Juri Lelli <juri.lelli@arm.com> - 2016-03-17 12:40 +0100
Re: [PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching Juri Lelli <juri.lelli@arm.com> - 2016-03-17 12:50 +0100
Re: [PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 14:00 +0100
Re: [PATCH v5 6/7][Update] cpufreq: Support for fast frequency switching Peter Zijlstra <peterz@infradead.org> - 2016-03-17 12:50 +0100
[PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-17 01:00 +0100
Re: [PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data Peter Zijlstra <peterz@infradead.org> - 2016-03-17 12:40 +0100
Re: [PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 14:00 +0100
Re: [PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data Juri Lelli <juri.lelli@arm.com> - 2016-03-17 12:40 +0100
Re: [PATCH v5 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 14:00 +0100
[PATCH v6 6/7][Update] cpufreq: Support for fast frequency switching "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-17 17:00 +0100
[PATCH v6 7/7][Update] cpufreq: schedutil: New governor based on scheduler utilization data "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-17 17:10 +0100
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-10 11:10 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rb5Hz-5r7-9@gated-at.bofh.it> |
| In reply to | #1354833 |
On Thu, Mar 10, 2016 at 10:44:21AM +0700, Vincent Guittot wrote: > We have the arch_scale_freq_capacity function that is arch dependent > and can be used to merge the 2 formula that were described by peter > above. > By default, arch_scale_freq_capacity return SCHED_CAPACITY_SCALE which > is max capacity > but when arch_scale_freq_capacity is defined by an architecture, > arch_scale_freq_capacity returns current_freq * max_capacity/max_freq However, current_freq is a very fluid thing, it might (and will) change very rapidly on some platforms. This is the same point I made earlier, you cannot try and divide out current_freq from the invariant measure. > so can't we use arch_scale_freq in your formula ? Taking your formula > above it becomes: > next_freq = 1.25 * current_freq * util / arch_scale_freq_capacity() No, that cannot work, nor makes any sense, per the above. > With invariance feature, we have: > > next_freq = 1.25 * current_freq * util / (current_freq*max_capacity/max_freq) > = 1.25 * util * max_freq / max > > which is the formula that has to be used with frequency invariant > utilization. Wrong, you cannot talk about current_freq in the invariant case. > May be we can pass arch_scale_freq_capacity value instead of max one > as a parameter of update_util function prototype No, since its a compile time thing, we can simply do: #ifdef arch_scale_freq_capacity next_freq = (1 + 1/n) * max_freq * (util / max) #else next_freq = (1 + 1/n) * current_freq * (util_raw / max) #endif
[toc] | [prev] | [next] | [standalone]
| From | Vincent Guittot <vincent.guittot@linaro.org> |
|---|---|
| Date | 2016-03-10 11:30 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rb60W-5G6-19@gated-at.bofh.it> |
| In reply to | #1354967 |
On 10 March 2016 at 17:07, Peter Zijlstra <peterz@infradead.org> wrote: > On Thu, Mar 10, 2016 at 10:44:21AM +0700, Vincent Guittot wrote: >> We have the arch_scale_freq_capacity function that is arch dependent >> and can be used to merge the 2 formula that were described by peter >> above. >> By default, arch_scale_freq_capacity return SCHED_CAPACITY_SCALE which >> is max capacity >> but when arch_scale_freq_capacity is defined by an architecture, > >> arch_scale_freq_capacity returns current_freq * max_capacity/max_freq > > However, current_freq is a very fluid thing, it might (and will) change > very rapidly on some platforms. > > This is the same point I made earlier, you cannot try and divide out > current_freq from the invariant measure. > >> so can't we use arch_scale_freq in your formula ? Taking your formula >> above it becomes: >> next_freq = 1.25 * current_freq * util / arch_scale_freq_capacity() > > No, that cannot work, nor makes any sense, per the above. > >> With invariance feature, we have: >> >> next_freq = 1.25 * current_freq * util / (current_freq*max_capacity/max_freq) >> = 1.25 * util * max_freq / max >> >> which is the formula that has to be used with frequency invariant >> utilization. > > Wrong, you cannot talk about current_freq in the invariant case. > >> May be we can pass arch_scale_freq_capacity value instead of max one >> as a parameter of update_util function prototype > > No, since its a compile time thing, we can simply do: > > #ifdef arch_scale_freq_capacity > next_freq = (1 + 1/n) * max_freq * (util / max) > #else > next_freq = (1 + 1/n) * current_freq * (util_raw / max) > #endif selecting formula at compilation is clearly better. I wrongly thought that it can't be accepted as a solution.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-10 11:40 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rb6aC-5KR-19@gated-at.bofh.it> |
| In reply to | #1354967 |
On Thu, Mar 10, 2016 at 05:23:54PM +0700, Vincent Guittot wrote: > > No, since its a compile time thing, we can simply do: > > > > #ifdef arch_scale_freq_capacity > > next_freq = (1 + 1/n) * max_freq * (util / max) > > #else > > next_freq = (1 + 1/n) * current_freq * (util_raw / max) > > #endif > > selecting formula at compilation is clearly better. I wrongly thought that > it can't be accepted as a solution. Well, its bound to get more 'interesting' since I forse implementations not always actually doing the invariant thing. Take for example the thing I send: lkml.kernel.org/r/20160303162829.GB6375@twins.programming.kicks-ass.net it both shows why you cannot talk about current_freq but also that the above needs a little more help (for the !X86_FEATURE_APERFMPERF case). But the !arch_scale_freq_capacity case should indeed be that simple.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-10 12:00 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rb6tY-5Tb-19@gated-at.bofh.it> |
| In reply to | #1354995 |
On Thu, Mar 10, 2016 at 11:30:08AM +0100, Peter Zijlstra wrote: > On Thu, Mar 10, 2016 at 05:23:54PM +0700, Vincent Guittot wrote: > > > > No, since its a compile time thing, we can simply do: > > > > > > #ifdef arch_scale_freq_capacity > > > next_freq = (1 + 1/n) * max_freq * (util / max) > > > #else > > > next_freq = (1 + 1/n) * current_freq * (util_raw / max) > > > #endif > > > > selecting formula at compilation is clearly better. I wrongly thought that > > it can't be accepted as a solution. > > Well, its bound to get more 'interesting' since I forse implementations > not always actually doing the invariant thing. > > Take for example the thing I send: > > lkml.kernel.org/r/20160303162829.GB6375@twins.programming.kicks-ass.net > > it both shows why you cannot talk about current_freq but also that the > above needs a little more help (for the !X86_FEATURE_APERFMPERF case). > > But the !arch_scale_freq_capacity case should indeed be that simple. Maybe something like: #ifdef arch_scale_freq_capacity #ifndef arch_scale_freq_invariant #define arch_scale_freq_invariant() (true) #endif #else /* arch_scale_freq_capacity */ #define arch_scale_freq_invariant() (false) #endif if (arch_scale_freq_invariant()) And have archs that have conditional arch_scale_freq_capacity() implementation provide a arch_scale_freq_invariant implementation.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-10 23:30 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rbhfI-51o-17@gated-at.bofh.it> |
| In reply to | #1355007 |
On Thursday, March 10, 2016 11:56:14 AM Peter Zijlstra wrote: > On Thu, Mar 10, 2016 at 11:30:08AM +0100, Peter Zijlstra wrote: > > On Thu, Mar 10, 2016 at 05:23:54PM +0700, Vincent Guittot wrote: > > > > > > No, since its a compile time thing, we can simply do: > > > > > > > > #ifdef arch_scale_freq_capacity > > > > next_freq = (1 + 1/n) * max_freq * (util / max) > > > > #else > > > > next_freq = (1 + 1/n) * current_freq * (util_raw / max) > > > > #endif > > > > > > selecting formula at compilation is clearly better. I wrongly thought that > > > it can't be accepted as a solution. > > > > Well, its bound to get more 'interesting' since I forse implementations > > not always actually doing the invariant thing. > > > > Take for example the thing I send: > > > > lkml.kernel.org/r/20160303162829.GB6375@twins.programming.kicks-ass.net > > > > it both shows why you cannot talk about current_freq but also that the > > above needs a little more help (for the !X86_FEATURE_APERFMPERF case). > > > > But the !arch_scale_freq_capacity case should indeed be that simple. > > Maybe something like: > > #ifdef arch_scale_freq_capacity > #ifndef arch_scale_freq_invariant > #define arch_scale_freq_invariant() (true) > #endif > #else /* arch_scale_freq_capacity */ > #define arch_scale_freq_invariant() (false) > #endif > > if (arch_scale_freq_invariant()) > > And have archs that have conditional arch_scale_freq_capacity() > implementation provide a arch_scale_freq_invariant implementation. Yeah, looks workable to me.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-10 09:50 +0100 |
| Subject | Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <rb4sa-4iX-15@gated-at.bofh.it> |
| In reply to | #1354595 |
On Thu, Mar 10, 2016 at 12:28:52AM +0100, Rafael J. Wysocki wrote: > > [ I would not have chosen (1 + 1/n), but lets stick to that ] > > Well, what would you choose then? :-) 1/p ; 0 < p < 1 or so. Where p then represents the percentile threshold where you want to bump to the next freq. > I think that should be > > next_freq = (1 + 1/n) * max_freq * util / max > > (where max is the second argument of cpufreq_update_util) or the > dimensions on both sides don't match. Well yes, but so far we were treating util (and util_raw) as 0 < u < 1, values, so already normalized against max. But yes.. > > if we substitute (2) into (3) we get: > > > > = (1 + 1/n) * max_freq * util_raw * current_freq / max_freq > > = (1 + 1/n) * current_freq * util_raw (4) > > > > Which gets you two formula with the same general behaviour. As (2) is > > the only approximation of (1) we can make. > > OK > > So since utilization is not frequency invariant in the current > mainline (or linux-next for that matter) AFAIC, I'm going to use the > following in the next version of the schedutil patch series: > > next_freq = 1.25 * current_freq * util_raw / max > > where util_raw and max are what I get from cpufreq_update_util(). > > 1.25 is for the 80% tipping point which I think is reasonable. OK.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <r8OKR-B1-1@gated-at.bofh.it> |
| In reply to | #1347699 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a new cpufreq scaling governor, called "schedutil", that uses
scheduler-provided CPU utilization information as input for making
its decisions.
Doing that is possible after commit fe7034338ba0 (cpufreq: Add
mechanism for registering utilization update callbacks) that
introduced cpufreq_update_util() called by the scheduler on
utilization changes (from CFS) and RT/DL task status updates.
In particular, CPU frequency scaling decisions may be based on
the the utilization data passed to cpufreq_update_util() by CFS.
The new governor is relatively simple.
The frequency selection formula used by it is
next_freq = util * max_freq / max
where util and max are the utilization and CPU capacity coming from CFS.
All of the computations are carried out in the utilization update
handlers provided by the new governor. One of those handlers is
used for cpufreq policies shared between multiple CPUs and the other
one is for policies with one CPU only (and therefore it doesn't need
to use any extra synchronization means).
The governor supports fast frequency switching if that is supported
by the cpufreq driver in use and possible for the given policy.
In the fast switching case, all operations of the governor take
place in its utilization update handlers. If fast switching cannot
be used, the frequency switch operations are carried out with the
help of a work item which only calls __cpufreq_driver_target()
(under a mutex) to trigger a frequency update (to a value already
computed beforehand in one of the utilization update handlers).
Currently, the governor treats all of the RT and DL tasks as
"unknown utilization" and sets the frequency to the allowed
maximum when updated from the RT or DL sched classes. That
heavy-handed approach should be replaced with something more
subtle and specifically targeted at RT and DL tasks.
The governor shares some sysfs attributes management code with
the "ondemand" and "conservative" governors and uses some common
definitions from cpufreq.h, but apart from that it is stand-alone.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Changes from the previous version:
- New frequency selection formula and modifications related to that.
- The file is now located in kernel/sched/.
Initially, I had hoped that it would be possible to split the code
into a library part that might go into kernel/sched/ and the governor
interface plus sysfs-related code, but that split would have been
artificial and I wanted the governor to be one module as a whole. So
that didn't work out.
Also the way it is configured and built is somewhat bizarre, as the
Kconfig options are in the cpufreq Kconfig, but the code they are
related to is located in kernel/sched/ (which is not exactly
straightforward).
Overall, I'd be happier if the governor could stay in drivers/cpufreq/.
---
drivers/cpufreq/Kconfig | 26 +
drivers/cpufreq/cpufreq_governor.h | 1
include/linux/cpufreq.h | 3
kernel/sched/Makefile | 1
kernel/sched/cpufreq_schedutil.c | 487 +++++++++++++++++++++++++++++++++++++
5 files changed, 517 insertions(+), 1 deletion(-)
Index: linux-pm/drivers/cpufreq/Kconfig
===================================================================
--- linux-pm.orig/drivers/cpufreq/Kconfig
+++ linux-pm/drivers/cpufreq/Kconfig
@@ -107,6 +107,16 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
Be aware that not all cpufreq drivers support the conservative
governor. If unsure have a look at the help section of the
driver. Fallback governor will be the performance governor.
+
+config CPU_FREQ_DEFAULT_GOV_SCHEDUTIL
+ bool "schedutil"
+ select CPU_FREQ_GOV_SCHEDUTIL
+ select CPU_FREQ_GOV_PERFORMANCE
+ help
+ Use the 'schedutil' CPUFreq governor by default. If unsure,
+ have a look at the help section of that governor. The fallback
+ governor will be 'performance'.
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
@@ -188,6 +198,22 @@ config CPU_FREQ_GOV_CONSERVATIVE
If in doubt, say N.
+config CPU_FREQ_GOV_SCHEDUTIL
+ tristate "'schedutil' cpufreq policy governor"
+ depends on CPU_FREQ
+ select CPU_FREQ_GOV_ATTR_SET
+ select IRQ_WORK
+ help
+ The frequency selection formula used by this governor is analogous
+ to the one used by 'ondemand', but instead of computing CPU load
+ as the "non-idle CPU time" to "total CPU time" ratio, it uses CPU
+ utilization data provided by the scheduler as input.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cpufreq_schedutil.
+
+ If in doubt, say N.
+
comment "CPU frequency scaling drivers"
config CPUFREQ_DT
Index: linux-pm/kernel/sched/cpufreq_schedutil.c
===================================================================
--- /dev/null
+++ linux-pm/kernel/sched/cpufreq_schedutil.c
@@ -0,0 +1,487 @@
+/*
+ * CPUFreq governor based on scheduler-provided CPU utilization data.
+ *
+ * Copyright (C) 2016, Intel Corporation
+ * Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+
+#include "sched.h"
+
+struct sugov_tunables {
+ struct gov_attr_set attr_set;
+ unsigned int rate_limit_us;
+};
+
+struct sugov_policy {
+ struct cpufreq_policy *policy;
+
+ struct sugov_tunables *tunables;
+ struct list_head tunables_hook;
+
+ raw_spinlock_t update_lock; /* For shared policies */
+ u64 last_freq_update_time;
+ s64 freq_update_delay_ns;
+ unsigned int next_freq;
+
+ /* The next fields are only needed if fast switch cannot be used. */
+ struct irq_work irq_work;
+ struct work_struct work;
+ struct mutex work_lock;
+ bool work_in_progress;
+
+ bool need_freq_update;
+};
+
+struct sugov_cpu {
+ struct freq_update_hook update_hook;
+ struct sugov_policy *sg_policy;
+
+ /* The fields below are only needed when sharing a policy. */
+ unsigned long util;
+ unsigned long max;
+ u64 last_update;
+};
+
+static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
+
+/************************ Governor internals ***********************/
+
+static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time)
+{
+ u64 delta_ns;
+
+ if (sg_policy->work_in_progress)
+ return false;
+
+ if (unlikely(sg_policy->need_freq_update)) {
+ sg_policy->need_freq_update = false;
+ return true;
+ }
+
+ delta_ns = time - sg_policy->last_freq_update_time;
+ return (s64)delta_ns >= sg_policy->freq_update_delay_ns;
+}
+
+static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
+ unsigned int next_freq)
+{
+ struct cpufreq_policy *policy = sg_policy->policy;
+
+ if (next_freq > policy->max)
+ next_freq = policy->max;
+ else if (next_freq < policy->min)
+ next_freq = policy->min;
+
+ sg_policy->last_freq_update_time = time;
+ if (sg_policy->next_freq == next_freq)
+ return;
+
+ sg_policy->next_freq = next_freq;
+ if (policy->fast_switch_possible) {
+ cpufreq_driver_fast_switch(policy, next_freq, CPUFREQ_RELATION_L);
+ } else {
+ sg_policy->work_in_progress = true;
+ irq_work_queue(&sg_policy->irq_work);
+ }
+}
+
+static void sugov_update_single(struct freq_update_hook *hook, u64 time,
+ unsigned long util, unsigned long max)
+{
+ struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_hook);
+ struct sugov_policy *sg_policy = sg_cpu->sg_policy;
+ unsigned int max_f, next_f;
+
+ if (!sugov_should_update_freq(sg_policy, time))
+ return;
+
+ max_f = sg_policy->policy->cpuinfo.max_freq;
+ next_f = util > max ? max_f : util * max_f / max;
+ sugov_update_commit(sg_policy, time, next_f);
+}
+
+static unsigned int sugov_next_freq(struct sugov_policy *sg_policy,
+ unsigned long util, unsigned long max)
+{
+ struct cpufreq_policy *policy = sg_policy->policy;
+ unsigned int max_f = policy->cpuinfo.max_freq;
+ u64 last_freq_update_time = sg_policy->last_freq_update_time;
+ unsigned int j;
+
+ if (util > max)
+ return max_f;
+
+ for_each_cpu(j, policy->cpus) {
+ struct sugov_cpu *j_sg_cpu;
+ unsigned long j_util, j_max;
+ u64 delta_ns;
+
+ if (j == smp_processor_id())
+ continue;
+
+ j_sg_cpu = &per_cpu(sugov_cpu, j);
+ /*
+ * If the CPU utilization was last updated before the previous
+ * frequency update and the time elapsed between the last update
+ * of the CPU utilization and the last frequency update is long
+ * enough, don't take the CPU into account as it probably is
+ * idle now.
+ */
+ delta_ns = last_freq_update_time - j_sg_cpu->last_update;
+ if ((s64)delta_ns > NSEC_PER_SEC / HZ)
+ continue;
+
+ j_util = j_sg_cpu->util;
+ j_max = j_sg_cpu->max;
+ if (j_util > j_max)
+ return max_f;
+
+ if (j_util * max > j_max * util) {
+ util = j_util;
+ max = j_max;
+ }
+ }
+
+ return util * max_f / max;
+}
+
+static void sugov_update_shared(struct freq_update_hook *hook, u64 time,
+ unsigned long util, unsigned long max)
+{
+ struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_hook);
+ struct sugov_policy *sg_policy = sg_cpu->sg_policy;
+ unsigned int next_f;
+
+ raw_spin_lock(&sg_policy->update_lock);
+
+ sg_cpu->util = util;
+ sg_cpu->max = max;
+ sg_cpu->last_update = time;
+
+ if (sugov_should_update_freq(sg_policy, time)) {
+ next_f = sugov_next_freq(sg_policy, util, max);
+ sugov_update_commit(sg_policy, time, next_f);
+ }
+
+ raw_spin_unlock(&sg_policy->update_lock);
+}
+
+static void sugov_work(struct work_struct *work)
+{
+ struct sugov_policy *sg_policy = container_of(work, struct sugov_policy, work);
+
+ mutex_lock(&sg_policy->work_lock);
+ __cpufreq_driver_target(sg_policy->policy, sg_policy->next_freq,
+ CPUFREQ_RELATION_L);
+ mutex_unlock(&sg_policy->work_lock);
+
+ sg_policy->work_in_progress = false;
+}
+
+static void sugov_irq_work(struct irq_work *irq_work)
+{
+ struct sugov_policy *sg_policy;
+
+ sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
+ schedule_work(&sg_policy->work);
+}
+
+/************************** sysfs interface ************************/
+
+static struct sugov_tunables *global_tunables;
+static DEFINE_MUTEX(global_tunables_lock);
+
+static inline struct sugov_tunables *to_sugov_tunables(struct gov_attr_set *attr_set)
+{
+ return container_of(attr_set, struct sugov_tunables, attr_set);
+}
+
+static ssize_t rate_limit_us_show(struct gov_attr_set *attr_set, char *buf)
+{
+ struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
+
+ return sprintf(buf, "%u\n", tunables->rate_limit_us);
+}
+
+static ssize_t rate_limit_us_store(struct gov_attr_set *attr_set, const char *buf,
+ size_t count)
+{
+ struct sugov_tunables *tunables = to_sugov_tunables(attr_set);
+ struct sugov_policy *sg_policy;
+ unsigned int rate_limit_us;
+ int ret;
+
+ ret = sscanf(buf, "%u", &rate_limit_us);
+ if (ret != 1)
+ return -EINVAL;
+
+ tunables->rate_limit_us = rate_limit_us;
+
+ list_for_each_entry(sg_policy, &attr_set->policy_list, tunables_hook)
+ sg_policy->freq_update_delay_ns = rate_limit_us * NSEC_PER_USEC;
+
+ return count;
+}
+
+static struct governor_attr rate_limit_us = __ATTR_RW(rate_limit_us);
+
+static struct attribute *sugov_attributes[] = {
+ &rate_limit_us.attr,
+ NULL
+};
+
+static struct kobj_type sugov_tunables_ktype = {
+ .default_attrs = sugov_attributes,
+ .sysfs_ops = &governor_sysfs_ops,
+};
+
+/********************** cpufreq governor interface *********************/
+
+static struct cpufreq_governor schedutil_gov;
+
+static struct sugov_policy *sugov_policy_alloc(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy;
+
+ sg_policy = kzalloc(sizeof(*sg_policy), GFP_KERNEL);
+ if (!sg_policy)
+ return NULL;
+
+ sg_policy->policy = policy;
+ init_irq_work(&sg_policy->irq_work, sugov_irq_work);
+ INIT_WORK(&sg_policy->work, sugov_work);
+ mutex_init(&sg_policy->work_lock);
+ raw_spin_lock_init(&sg_policy->update_lock);
+ return sg_policy;
+}
+
+static void sugov_policy_free(struct sugov_policy *sg_policy)
+{
+ mutex_destroy(&sg_policy->work_lock);
+ kfree(sg_policy);
+}
+
+static struct sugov_tunables *sugov_tunables_alloc(struct sugov_policy *sg_policy)
+{
+ struct sugov_tunables *tunables;
+
+ tunables = kzalloc(sizeof(*tunables), GFP_KERNEL);
+ if (tunables)
+ gov_attr_set_init(&tunables->attr_set, &sg_policy->tunables_hook);
+
+ return tunables;
+}
+
+static void sugov_tunables_free(struct sugov_tunables *tunables)
+{
+ if (!have_governor_per_policy())
+ global_tunables = NULL;
+
+ kfree(tunables);
+}
+
+static int sugov_init(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy;
+ struct sugov_tunables *tunables;
+ unsigned int lat;
+ int ret = 0;
+
+ /* State should be equivalent to EXIT */
+ if (policy->governor_data)
+ return -EBUSY;
+
+ sg_policy = sugov_policy_alloc(policy);
+ if (!sg_policy)
+ return -ENOMEM;
+
+ mutex_lock(&global_tunables_lock);
+
+ if (global_tunables) {
+ if (WARN_ON(have_governor_per_policy())) {
+ ret = -EINVAL;
+ goto free_sg_policy;
+ }
+ policy->governor_data = sg_policy;
+ sg_policy->tunables = global_tunables;
+
+ gov_attr_set_get(&global_tunables->attr_set, &sg_policy->tunables_hook);
+ goto out;
+ }
+
+ tunables = sugov_tunables_alloc(sg_policy);
+ if (!tunables) {
+ ret = -ENOMEM;
+ goto free_sg_policy;
+ }
+
+ tunables->rate_limit_us = LATENCY_MULTIPLIER;
+ lat = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
+ if (lat)
+ tunables->rate_limit_us *= lat;
+
+ if (!have_governor_per_policy())
+ global_tunables = tunables;
+
+ policy->governor_data = sg_policy;
+ sg_policy->tunables = tunables;
+
+ ret = kobject_init_and_add(&tunables->attr_set.kobj, &sugov_tunables_ktype,
+ get_governor_parent_kobj(policy), "%s",
+ schedutil_gov.name);
+ if (!ret)
+ goto out;
+
+ /* Failure, so roll back. */
+ policy->governor_data = NULL;
+ sugov_tunables_free(tunables);
+
+ free_sg_policy:
+ pr_err("cpufreq: schedutil governor initialization failed (error %d)\n", ret);
+ sugov_policy_free(sg_policy);
+
+ out:
+ mutex_unlock(&global_tunables_lock);
+ return ret;
+}
+
+static int sugov_exit(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy = policy->governor_data;
+ struct sugov_tunables *tunables = sg_policy->tunables;
+ unsigned int count;
+
+ mutex_lock(&global_tunables_lock);
+
+ count = gov_attr_set_put(&tunables->attr_set, &sg_policy->tunables_hook);
+ policy->governor_data = NULL;
+ if (!count)
+ sugov_tunables_free(tunables);
+
+ mutex_unlock(&global_tunables_lock);
+
+ sugov_policy_free(sg_policy);
+ return 0;
+}
+
+static int sugov_start(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy = policy->governor_data;
+ unsigned int cpu;
+
+ sg_policy->freq_update_delay_ns = sg_policy->tunables->rate_limit_us * NSEC_PER_USEC;
+ sg_policy->last_freq_update_time = 0;
+ sg_policy->next_freq = UINT_MAX;
+ sg_policy->work_in_progress = false;
+ sg_policy->need_freq_update = false;
+
+ for_each_cpu(cpu, policy->cpus) {
+ struct sugov_cpu *sg_cpu = &per_cpu(sugov_cpu, cpu);
+
+ sg_cpu->sg_policy = sg_policy;
+ if (policy_is_shared(policy)) {
+ sg_cpu->util = ULONG_MAX;
+ sg_cpu->max = 0;
+ sg_cpu->last_update = 0;
+ cpufreq_set_update_util_hook(cpu, &sg_cpu->update_hook,
+ sugov_update_shared);
+ } else {
+ cpufreq_set_update_util_hook(cpu, &sg_cpu->update_hook,
+ sugov_update_single);
+ }
+ }
+ return 0;
+}
+
+static int sugov_stop(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy = policy->governor_data;
+ unsigned int cpu;
+
+ for_each_cpu(cpu, policy->cpus)
+ cpufreq_clear_update_util_hook(cpu);
+
+ synchronize_sched();
+
+ irq_work_sync(&sg_policy->irq_work);
+ cancel_work_sync(&sg_policy->work);
+ return 0;
+}
+
+static int sugov_limits(struct cpufreq_policy *policy)
+{
+ struct sugov_policy *sg_policy = policy->governor_data;
+
+ if (!policy->fast_switch_possible) {
+ mutex_lock(&sg_policy->work_lock);
+
+ if (policy->max < policy->cur)
+ __cpufreq_driver_target(policy, policy->max,
+ CPUFREQ_RELATION_H);
+ else if (policy->min > policy->cur)
+ __cpufreq_driver_target(policy, policy->min,
+ CPUFREQ_RELATION_L);
+
+ mutex_unlock(&sg_policy->work_lock);
+ }
+
+ sg_policy->need_freq_update = true;
+ return 0;
+}
+
+int sugov_governor(struct cpufreq_policy *policy, unsigned int event)
+{
+ if (event == CPUFREQ_GOV_POLICY_INIT) {
+ return sugov_init(policy);
+ } else if (policy->governor_data) {
+ switch (event) {
+ case CPUFREQ_GOV_POLICY_EXIT:
+ return sugov_exit(policy);
+ case CPUFREQ_GOV_START:
+ return sugov_start(policy);
+ case CPUFREQ_GOV_STOP:
+ return sugov_stop(policy);
+ case CPUFREQ_GOV_LIMITS:
+ return sugov_limits(policy);
+ }
+ }
+ return -EINVAL;
+}
+
+static struct cpufreq_governor schedutil_gov = {
+ .name = "schedutil",
+ .governor = sugov_governor,
+ .owner = THIS_MODULE,
+};
+
+static int __init sugov_module_init(void)
+{
+ return cpufreq_register_governor(&schedutil_gov);
+}
+
+static void __exit sugov_module_exit(void)
+{
+ cpufreq_unregister_governor(&schedutil_gov);
+}
+
+MODULE_AUTHOR("Rafael J. Wysocki <rafael.j.wysocki@intel.com>");
+MODULE_DESCRIPTION("Utilization-based CPU frequency selection");
+MODULE_LICENSE("GPL");
+
+#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL
+struct cpufreq_governor *cpufreq_default_governor(void)
+{
+ return &schedutil_gov;
+}
+
+fs_initcall(sugov_module_init);
+#else
+module_init(sugov_module_init);
+#endif
+module_exit(sugov_module_exit);
Index: linux-pm/kernel/sched/Makefile
===================================================================
--- linux-pm.orig/kernel/sched/Makefile
+++ linux-pm/kernel/sched/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_SCHEDSTATS) += stats.o
obj-$(CONFIG_SCHED_DEBUG) += debug.o
obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
+obj-$(CONFIG_CPU_FREQ_GOV_SCHEDUTIL) += cpufreq_schedutil.o
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -34,7 +34,6 @@
* this governor will not work. All times here are in us (micro seconds).
*/
#define MIN_SAMPLING_RATE_RATIO (2)
-#define LATENCY_MULTIPLIER (1000)
#define MIN_LATENCY_MULTIPLIER (20)
#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000)
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -468,6 +468,9 @@ void cpufreq_unregister_governor(struct
struct cpufreq_governor *cpufreq_default_governor(void);
struct cpufreq_governor *cpufreq_fallback_governor(void);
+/* Coefficient for computing default sampling rate/rate limit in governors */
+#define LATENCY_MULTIPLIER (1000)
+
/* Governor attribute set */
struct gov_attr_set {
struct kobject kobj;
[toc] | [prev] | [next] | [standalone]
| From | Juri Lelli <juri.lelli@arm.com> |
|---|---|
| Date | 2016-03-04 12:30 +0100 |
| Subject | Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <r8W5H-5SG-1@gated-at.bofh.it> |
| In reply to | #1349811 |
Hi Rafael, On 04/03/16 04:35, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Add a new cpufreq scaling governor, called "schedutil", that uses > scheduler-provided CPU utilization information as input for making > its decisions. > > Doing that is possible after commit fe7034338ba0 (cpufreq: Add > mechanism for registering utilization update callbacks) that > introduced cpufreq_update_util() called by the scheduler on > utilization changes (from CFS) and RT/DL task status updates. > In particular, CPU frequency scaling decisions may be based on > the the utilization data passed to cpufreq_update_util() by CFS. > > The new governor is relatively simple. > > The frequency selection formula used by it is > > next_freq = util * max_freq / max > > where util and max are the utilization and CPU capacity coming from CFS. > The formula looks better to me now. However, problem is that, if you have freq. invariance, util will slowly saturate to the current capacity. So, we won't trigger OPP changes for a task that for example starts light and then becomes big. This is the same problem we faced with schedfreq. The current solution there is to use a margin for calculating a threshold (80% of current capacity ATM). Once util goes above that threshold we trigger an OPP change. Current policy is pretty aggressive, we go to max_f and then adapt to the "real" util during successive enqueues. This was also tought to cope with the fact that PELT seems slow to react to abrupt changes in tasks behaviour. I'm not saying this is the definitive solution, but I fear something along this line is needed when you add freq invariance in the mix. Best, - Juri
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-04 14:20 +0100 |
| Subject | Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <r8XOa-7kY-1@gated-at.bofh.it> |
| In reply to | #1350165 |
On Fri, Mar 4, 2016 at 12:26 PM, Juri Lelli <juri.lelli@arm.com> wrote: > Hi Rafael, Hi, > On 04/03/16 04:35, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> Add a new cpufreq scaling governor, called "schedutil", that uses >> scheduler-provided CPU utilization information as input for making >> its decisions. >> >> Doing that is possible after commit fe7034338ba0 (cpufreq: Add >> mechanism for registering utilization update callbacks) that >> introduced cpufreq_update_util() called by the scheduler on >> utilization changes (from CFS) and RT/DL task status updates. >> In particular, CPU frequency scaling decisions may be based on >> the the utilization data passed to cpufreq_update_util() by CFS. >> >> The new governor is relatively simple. >> >> The frequency selection formula used by it is >> >> next_freq = util * max_freq / max >> >> where util and max are the utilization and CPU capacity coming from CFS. >> > > The formula looks better to me now. However, problem is that, if you > have freq. invariance, util will slowly saturate to the current > capacity. So, we won't trigger OPP changes for a task that for example > starts light and then becomes big. > > This is the same problem we faced with schedfreq. The current solution > there is to use a margin for calculating a threshold (80% of current > capacity ATM). Once util goes above that threshold we trigger an OPP > change. Current policy is pretty aggressive, we go to max_f and then > adapt to the "real" util during successive enqueues. This was also > tought to cope with the fact that PELT seems slow to react to abrupt > changes in tasks behaviour. > > I'm not saying this is the definitive solution, but I fear something > along this line is needed when you add freq invariance in the mix. I really would like to avoid adding factors that need to be determined experimentally, because the result of that tends to depend on the system where the experiment is carried out and tunables simply don't work (99% or maybe even more users don't change the defaults anyway). So I would really like to use a formula that's based on some science and doesn't depend on additional input. Now, since the equation generally is f = a * x + b (f - frequency, x = util/max) and there are good arguments for b = 0, it all boils down to what number to take as a. a = max_freq is a good candidate (that's what I'm using right now), but it may turn out to be too small. Another reasonable candidate is a = min_freq + max_freq, because then x = 0.5 selects the frequency in the middle of the available range, but that may turn out to be way too big if min_freq is high (like higher that 50% of max_freq). I need to think more about that and admittedly my understanding of the frequency invariance consequences is limited ATM. Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
| From | Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
|---|---|
| Date | 2016-03-04 17:00 +0100 |
| Subject | Re: [PATCH v2 10/10] cpufreq: schedutil: New governor based on scheduler utilization data |
| Message-ID | <r90j0-qK-21@gated-at.bofh.it> |
| In reply to | #1350165 |
On Fri, 2016-03-04 at 11:26 +0000, Juri Lelli wrote: > Hi Rafael, > > On 04/03/16 04:35, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Add a new cpufreq scaling governor, called "schedutil", that uses > > scheduler-provided CPU utilization information as input for making > > its decisions. > > > > Doing that is possible after commit fe7034338ba0 (cpufreq: Add > > mechanism for registering utilization update callbacks) that > > introduced cpufreq_update_util() called by the scheduler on > > utilization changes (from CFS) and RT/DL task status updates. > > In particular, CPU frequency scaling decisions may be based on > > the the utilization data passed to cpufreq_update_util() by CFS. > > > > The new governor is relatively simple. > > > > The frequency selection formula used by it is > > > > next_freq = util * max_freq / max > > > > where util and max are the utilization and CPU capacity coming from > > CFS. > > > > The formula looks better to me now. However, problem is that, if you > have freq. invariance, util will slowly saturate to the current > capacity. So, we won't trigger OPP changes for a task that for > example > starts light and then becomes big. > > This is the same problem we faced with schedfreq. The current > solution > there is to use a margin for calculating a threshold (80% of current > capacity ATM). Once util goes above that threshold we trigger an OPP > change. Current policy is pretty aggressive, we go to max_f and then > adapt to the "real" util during successive enqueues. This was also > tought to cope with the fact that PELT seems slow to react to abrupt > changes in tasks behaviour. > I also tried something like this in intel_pstate with scheduler util, where you ramp up to turbo when a threshold percent exceeded then ramp down slowly in steps. This helped some workloads like tbench to perform better, but it resulted in lower performance/watt on specpower server workload. The problem is finding what is the right threshold value. Thanks, Srinivas > I'm not saying this is the definitive solution, but I fear something > along this line is needed when you add freq invariance in the mix. > > Best, > > - Juri > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r8OKR-B1-5@gated-at.bofh.it> |
| In reply to | #1347699 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Modify the ACPI cpufreq driver to provide a method for switching
CPU frequencies from interrupt context and update the cpufreq core
to support that method if available.
Introduce a new cpufreq driver callback, ->fast_switch, to be
invoked for frequency switching from interrupt context via a
new helper function, cpufreq_driver_fast_switch(). Add a new
policy flag, fast_switch_possible, to be set if fast frequency
switching can be used for the given policy.
Implement the ->fast_switch callback in the ACPI cpufreq driver
and make it set fast_switch_possible during policy initialization
as appropriate.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Changes from the previous version:
- Drop a bogus check from cpufreq_driver_fast_switch().
---
drivers/cpufreq/acpi-cpufreq.c | 53 +++++++++++++++++++++++++++++++++++++++++
drivers/cpufreq/cpufreq.c | 30 +++++++++++++++++++++++
include/linux/cpufreq.h | 6 ++++
3 files changed, 89 insertions(+)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -458,6 +458,55 @@ static int acpi_cpufreq_target(struct cp
return result;
}
+unsigned int acpi_cpufreq_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ struct acpi_cpufreq_data *data = policy->driver_data;
+ struct acpi_processor_performance *perf;
+ struct cpufreq_frequency_table *entry, *found;
+ unsigned int next_perf_state, next_freq, freq;
+
+ /*
+ * Find the closest frequency above target_freq or equal to it.
+ *
+ * The table is sorted in the reverse order with respect to the
+ * frequency and all of the entries are valid (see the initialization).
+ */
+ entry = data->freq_table;
+ do {
+ entry++;
+ freq = entry->frequency;
+ } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
+ found = entry - 1;
+ /*
+ * Use the one found or the previous one, depending on the relation.
+ * CPUFREQ_RELATION_H is not taken into account here, but it is not
+ * expected to be passed to this function anyway.
+ */
+ next_freq = found->frequency;
+ if (freq == CPUFREQ_TABLE_END || relation != CPUFREQ_RELATION_C ||
+ target_freq - freq >= next_freq - target_freq) {
+ next_perf_state = found->driver_data;
+ } else {
+ next_freq = freq;
+ next_perf_state = entry->driver_data;
+ }
+
+ perf = to_perf_data(data);
+ if (perf->state == next_perf_state) {
+ if (unlikely(data->resume))
+ data->resume = 0;
+ else
+ return next_freq;
+ }
+
+ data->cpu_freq_write(&perf->control_register,
+ perf->states[next_perf_state].control);
+ perf->state = next_perf_state;
+ return next_freq;
+}
+
static unsigned long
acpi_cpufreq_guess_freq(struct acpi_cpufreq_data *data, unsigned int cpu)
{
@@ -740,6 +789,9 @@ static int acpi_cpufreq_cpu_init(struct
goto err_unreg;
}
+ policy->fast_switch_possible = !acpi_pstate_strict &&
+ !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
+
data->freq_table = kzalloc(sizeof(*data->freq_table) *
(perf->state_count+1), GFP_KERNEL);
if (!data->freq_table) {
@@ -874,6 +926,7 @@ static struct freq_attr *acpi_cpufreq_at
static struct cpufreq_driver acpi_cpufreq_driver = {
.verify = cpufreq_generic_frequency_table_verify,
.target_index = acpi_cpufreq_target,
+ .fast_switch = acpi_cpufreq_fast_switch,
.bios_limit = acpi_processor_get_bios_limit,
.init = acpi_cpufreq_cpu_init,
.exit = acpi_cpufreq_cpu_exit,
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -1719,6 +1719,36 @@ EXPORT_SYMBOL(cpufreq_unregister_notifie
* GOVERNORS *
*********************************************************************/
+/**
+ * cpufreq_driver_fast_switch - Carry out a fast CPU frequency switch.
+ * @policy: cpufreq policy to switch the frequency for.
+ * @target_freq: New frequency to set (may be approximate).
+ * @relation: Relation to use for frequency selection.
+ *
+ * Carry out a fast frequency switch from interrupt context.
+ *
+ * This function must not be called if policy->fast_switch_possible is unset.
+ *
+ * Governors calling this function must guarantee that it will never be invoked
+ * twice in parallel for the same policy and that it will never be called in
+ * parallel with either ->target() or ->target_index() for the same policy.
+ *
+ * If CPUFREQ_ENTRY_INVALID is returned by the driver's ->fast_switch()
+ * callback, the hardware configuration must be preserved.
+ */
+void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation)
+{
+ unsigned int freq;
+
+ freq = cpufreq_driver->fast_switch(policy, target_freq, relation);
+ if (freq != CPUFREQ_ENTRY_INVALID) {
+ policy->cur = freq;
+ trace_cpu_frequency(freq, smp_processor_id());
+ }
+}
+EXPORT_SYMBOL_GPL(cpufreq_driver_fast_switch);
+
/* Must set freqs->new to intermediate frequency */
static int __target_intermediate(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, int index)
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -81,6 +81,7 @@ struct cpufreq_policy {
struct cpufreq_governor *governor; /* see below */
void *governor_data;
char last_governor[CPUFREQ_NAME_LEN]; /* last governor used */
+ bool fast_switch_possible;
struct work_struct update; /* if update_policy() needs to be
* called, but you're in IRQ context */
@@ -236,6 +237,9 @@ struct cpufreq_driver {
unsigned int relation); /* Deprecated */
int (*target_index)(struct cpufreq_policy *policy,
unsigned int index);
+ unsigned int (*fast_switch)(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation);
/*
* Only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION
* unset.
@@ -450,6 +454,8 @@ struct cpufreq_governor {
};
/* Pass a target to the cpufreq driver */
+void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation);
int cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation);
[toc] | [prev] | [next] | [standalone]
| From | Steve Muckle <steve.muckle@linaro.org> |
|---|---|
| Date | 2016-03-04 23:20 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r96eK-57r-11@gated-at.bofh.it> |
| In reply to | #1349812 |
On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:
> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
> + unsigned int target_freq, unsigned int relation)
> +{
> + unsigned int freq;
> +
> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation);
> + if (freq != CPUFREQ_ENTRY_INVALID) {
> + policy->cur = freq;
> + trace_cpu_frequency(freq, smp_processor_id());
> + }
> +}
Even if there are platforms which may change the CPU frequency behind
cpufreq's back, breaking the transition notifiers, I'm worried about the
addition of an interface which itself breaks them. The platforms which
do change CPU frequency on their own have probably evolved to live with
or work around this behavior. As other platforms migrate to fast
frequency switching they might be surprised when things don't work as
advertised.
I'm not sure what the easiest way to deal with this is. I see the
transition notifiers are the srcu type, which I understand to be
blocking. Going through the tree and reworking everyone's callbacks and
changing the type to atomic is obviously not realistic.
How about modifying cpufreq_register_notifier to return an error if the
driver has a fast_switch callback installed and an attempt to register a
transition notifier is made?
In the future, perhaps an additional atomic transition callback type can
be added, which platform/driver owners can switch to if they wish to use
fast transitions with their platform.
thanks,
Steve
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-04 23:40 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r96y7-5hB-35@gated-at.bofh.it> |
| In reply to | #1350642 |
On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:
>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
>> + unsigned int target_freq, unsigned int relation)
>> +{
>> + unsigned int freq;
>> +
>> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation);
>> + if (freq != CPUFREQ_ENTRY_INVALID) {
>> + policy->cur = freq;
>> + trace_cpu_frequency(freq, smp_processor_id());
>> + }
>> +}
>
> Even if there are platforms which may change the CPU frequency behind
> cpufreq's back, breaking the transition notifiers, I'm worried about the
> addition of an interface which itself breaks them. The platforms which
> do change CPU frequency on their own have probably evolved to live with
> or work around this behavior. As other platforms migrate to fast
> frequency switching they might be surprised when things don't work as
> advertised.
Well, intel_pstate doesn't do notifies at all, so anything depending
on them is already broken when it is used. Let alone the hardware
P-states coordination mechanism (HWP) where the frequency is
controlled by the processor itself entirely.
That said I see your point.
> I'm not sure what the easiest way to deal with this is. I see the
> transition notifiers are the srcu type, which I understand to be
> blocking. Going through the tree and reworking everyone's callbacks and
> changing the type to atomic is obviously not realistic.
Right.
> How about modifying cpufreq_register_notifier to return an error if the
> driver has a fast_switch callback installed and an attempt to register a
> transition notifier is made?
That sounds like a good idea.
There also is the CPUFREQ_ASYNC_NOTIFICATION driver flag that in
principle might be used as a workaround, but I'm not sure how much
work that would require ATM.
> In the future, perhaps an additional atomic transition callback type can
> be added, which platform/driver owners can switch to if they wish to use
> fast transitions with their platform.
I guess you mean an atomic notification mechanism based on registering
callbacks? While technically viable that's somewhat risky, because we
are in a fast path and allowing anyone to add stuff to it would be
asking for trouble IMO.
Thanks,
Rafael
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-04 23:50 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r96HL-5lt-3@gated-at.bofh.it> |
| In reply to | #1350653 |
On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
>> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:
>>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
>>> + unsigned int target_freq, unsigned int relation)
>>> +{
>>> + unsigned int freq;
>>> +
>>> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation);
>>> + if (freq != CPUFREQ_ENTRY_INVALID) {
>>> + policy->cur = freq;
>>> + trace_cpu_frequency(freq, smp_processor_id());
>>> + }
>>> +}
>>
>> Even if there are platforms which may change the CPU frequency behind
>> cpufreq's back, breaking the transition notifiers, I'm worried about the
>> addition of an interface which itself breaks them. The platforms which
>> do change CPU frequency on their own have probably evolved to live with
>> or work around this behavior. As other platforms migrate to fast
>> frequency switching they might be surprised when things don't work as
>> advertised.
>
> Well, intel_pstate doesn't do notifies at all, so anything depending
> on them is already broken when it is used. Let alone the hardware
> P-states coordination mechanism (HWP) where the frequency is
> controlled by the processor itself entirely.
>
> That said I see your point.
>
>> I'm not sure what the easiest way to deal with this is. I see the
>> transition notifiers are the srcu type, which I understand to be
>> blocking. Going through the tree and reworking everyone's callbacks and
>> changing the type to atomic is obviously not realistic.
>
> Right.
>
>> How about modifying cpufreq_register_notifier to return an error if the
>> driver has a fast_switch callback installed and an attempt to register a
>> transition notifier is made?
>
> That sounds like a good idea.
>
> There also is the CPUFREQ_ASYNC_NOTIFICATION driver flag that in
> principle might be used as a workaround, but I'm not sure how much
> work that would require ATM.
What I mean is that drivers using it are supposed to handle the
notifications by calling cpufreq_freq_transition_begin(/end() by
themselves, so theoretically there is a mechanism already in place for
that.
I guess what might be done would be to spawn a work item to carry out
a notify when the frequency changes.
Thanks,
Rafael
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-05 00:20 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r97aO-5LC-3@gated-at.bofh.it> |
| In reply to | #1350656 |
On Fri, Mar 4, 2016 at 11:40 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
>>> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:
>>>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
>>>> + unsigned int target_freq, unsigned int relation)
>>>> +{
>>>> + unsigned int freq;
>>>> +
>>>> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation);
>>>> + if (freq != CPUFREQ_ENTRY_INVALID) {
>>>> + policy->cur = freq;
>>>> + trace_cpu_frequency(freq, smp_processor_id());
>>>> + }
>>>> +}
>>>
>>> Even if there are platforms which may change the CPU frequency behind
>>> cpufreq's back, breaking the transition notifiers, I'm worried about the
>>> addition of an interface which itself breaks them. The platforms which
>>> do change CPU frequency on their own have probably evolved to live with
>>> or work around this behavior. As other platforms migrate to fast
>>> frequency switching they might be surprised when things don't work as
>>> advertised.
>>
>> Well, intel_pstate doesn't do notifies at all, so anything depending
>> on them is already broken when it is used. Let alone the hardware
>> P-states coordination mechanism (HWP) where the frequency is
>> controlled by the processor itself entirely.
>>
>> That said I see your point.
>>
>>> I'm not sure what the easiest way to deal with this is. I see the
>>> transition notifiers are the srcu type, which I understand to be
>>> blocking. Going through the tree and reworking everyone's callbacks and
>>> changing the type to atomic is obviously not realistic.
>>
>> Right.
>>
>>> How about modifying cpufreq_register_notifier to return an error if the
>>> driver has a fast_switch callback installed and an attempt to register a
>>> transition notifier is made?
>>
>> That sounds like a good idea.
>>
>> There also is the CPUFREQ_ASYNC_NOTIFICATION driver flag that in
>> principle might be used as a workaround, but I'm not sure how much
>> work that would require ATM.
>
> What I mean is that drivers using it are supposed to handle the
> notifications by calling cpufreq_freq_transition_begin(/end() by
> themselves, so theoretically there is a mechanism already in place for
> that.
>
> I guess what might be done would be to spawn a work item to carry out
> a notify when the frequency changes.
In fact, the mechanism may be relatively simple if I'm not mistaken.
In the "fast switch" case, the governor may spawn a work item that
will just execute cpufreq_get() on policy->cpu. That will notice that
policy->cur is different from the real current frequency and will
re-adjust.
Of course, cpufreq_driver_fast_switch() will need to be modified so it
doesn't update policy->cur then perhaps with a comment that the
governor using it will be responsible for that.
And the governor will need to avoid spawning that work item too often
(basically, if one has been spawned already and hasn't completed, no
need to spawn a new one, and maybe rate-limit it?), but all that looks
reasonably straightforward.
Thanks,
Rafael
[toc] | [prev] | [next] | [standalone]
| From | Steve Muckle <steve.muckle@linaro.org> |
|---|---|
| Date | 2016-03-05 01:00 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r97Nw-633-5@gated-at.bofh.it> |
| In reply to | #1350672 |
On 03/04/2016 03:18 PM, Rafael J. Wysocki wrote: > In fact, the mechanism may be relatively simple if I'm not mistaken. > > In the "fast switch" case, the governor may spawn a work item that > will just execute cpufreq_get() on policy->cpu. That will notice that > policy->cur is different from the real current frequency and will > re-adjust. > > Of course, cpufreq_driver_fast_switch() will need to be modified so it > doesn't update policy->cur then perhaps with a comment that the > governor using it will be responsible for that. > > And the governor will need to avoid spawning that work item too often > (basically, if one has been spawned already and hasn't completed, no > need to spawn a new one, and maybe rate-limit it?), but all that looks > reasonably straightforward. It is another option though definitely a compromise. The semantics seem different since you'd potentially have multiple freq changes before a single notifier went through, so stuff might still break. The fast path would also be more expensive given the workqueue activity that could translate into additional task wakeups. Honestly I wonder if it's better to just try the "no notifiers with fast drivers" approach to start. The notifiers could always be added if platform owners complain that they absolutely require them. thanks, Steve
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-05 01:20 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r986S-6pu-5@gated-at.bofh.it> |
| In reply to | #1350688 |
On Sat, Mar 5, 2016 at 12:56 AM, Steve Muckle <steve.muckle@linaro.org> wrote: > On 03/04/2016 03:18 PM, Rafael J. Wysocki wrote: >> In fact, the mechanism may be relatively simple if I'm not mistaken. >> >> In the "fast switch" case, the governor may spawn a work item that >> will just execute cpufreq_get() on policy->cpu. That will notice that >> policy->cur is different from the real current frequency and will >> re-adjust. >> >> Of course, cpufreq_driver_fast_switch() will need to be modified so it >> doesn't update policy->cur then perhaps with a comment that the >> governor using it will be responsible for that. >> >> And the governor will need to avoid spawning that work item too often >> (basically, if one has been spawned already and hasn't completed, no >> need to spawn a new one, and maybe rate-limit it?), but all that looks >> reasonably straightforward. > > It is another option though definitely a compromise. The semantics seem > different since you'd potentially have multiple freq changes before a > single notifier went through, so stuff might still break. Here I'm not worried. That's basically equivalent to someone doing a "get" and seeing an unexpected frequency in the driver output which is covered already and things need to cope with it or they are just really broken. > The fast path would also be more expensive given the workqueue activity that could > translate into additional task wakeups. That's a valid concern, so maybe there can be a driver flag to indicate that this has to be done if ->fast_switch is in use? Or something like fast_switch_notify_rate that will tell the governor how often to notify things about transitions if ->fast_switch is in use with either 0 or all ones meaning "never"? That might be a policy property even, so the driver may set this depending on what platform it is used on. > Honestly I wonder if it's better to just try the "no notifiers with fast > drivers" approach to start. The notifiers could always be added if > platform owners complain that they absolutely require them. Well, I'm not sure what happens if we start to fail notifier registrations. It may not be a well tested error code path. :-) Besides, there is the problem with registering notifiers before the driver and I don't think we can fail driver registration if notifiers have already been registered. We may not be able to register a "fast" driver at all in that case. But that whole thing is your worry, not mine. :-) Had I been worrying about that, I would have added some bandaid for that to the patches. Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2016-03-05 13:00 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r9j2i-5EO-9@gated-at.bofh.it> |
| In reply to | #1350698 |
* Rafael J. Wysocki <rafael@kernel.org> wrote: > > Honestly I wonder if it's better to just try the "no notifiers with fast > > drivers" approach to start. The notifiers could always be added if platform > > owners complain that they absolutely require them. > > Well, I'm not sure what happens if we start to fail notifier registrations. It > may not be a well tested error code path. :-) Yeah, so as a general principle 'struct notifier_block' as a really bad interface with poor and fragile semantics, and we are trying to get rid of them everywhere from core kernel code. For example Thomas Gleixner et al is working on eliminating them from the CPU hotplug code - which will get rid of most remaining notifier uses from the scheduler as well. So please add explicit cpufreq driver callback functions instead, which can be filled in by a platform if needed. No notifiers! Thanks, Ingo
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-05 17:50 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r9nyW-sx-13@gated-at.bofh.it> |
| In reply to | #1350672 |
On Sat, Mar 05, 2016 at 12:18:54AM +0100, Rafael J. Wysocki wrote: > >>> Even if there are platforms which may change the CPU frequency behind > >>> cpufreq's back, breaking the transition notifiers, I'm worried about the > >>> addition of an interface which itself breaks them. The platforms which > >>> do change CPU frequency on their own have probably evolved to live with > >>> or work around this behavior. As other platforms migrate to fast > >>> frequency switching they might be surprised when things don't work as > >>> advertised. There's only 43 sites of cpufreq_register_notifier in 37 files, that should be fairly simple to audit. > >>> I'm not sure what the easiest way to deal with this is. I see the > >>> transition notifiers are the srcu type, which I understand to be > >>> blocking. Going through the tree and reworking everyone's callbacks and > >>> changing the type to atomic is obviously not realistic. > >> > >> Right. Even if it was (and per the above it looks entirely feasible), that's just not going to happen. We're not ever going to call random notifier crap from this deep within the scheduler. > >>> How about modifying cpufreq_register_notifier to return an error if the > >>> driver has a fast_switch callback installed and an attempt to register a > >>> transition notifier is made? > >> > >> That sounds like a good idea. Agreed, fail the stuff hard. Simply make cpufreq_register_notifier a __must_check function and add error handling to all call sites. > > I guess what might be done would be to spawn a work item to carry out > > a notify when the frequency changes. > > In fact, the mechanism may be relatively simple if I'm not mistaken. > > In the "fast switch" case, the governor may spawn a work item that > will just execute cpufreq_get() on policy->cpu. That will notice that > policy->cur is different from the real current frequency and will > re-adjust. > > Of course, cpufreq_driver_fast_switch() will need to be modified so it > doesn't update policy->cur then perhaps with a comment that the > governor using it will be responsible for that. No no no, that's just horrible. Why would you want to keep this notification stuff alive? If your platform can change frequency 'fast' you don't want notifiers. What's the point of a notification that says: "At some point in the random past my frequency has changed, and it likely has changed again since then, do 'something'." That's pointless. If you have dependent clock domains or whatever, you simply _cannot_ be fast.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-06 03:20 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r9wsy-6Vu-3@gated-at.bofh.it> |
| In reply to | #1350934 |
On Sat, Mar 5, 2016 at 5:49 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Sat, Mar 05, 2016 at 12:18:54AM +0100, Rafael J. Wysocki wrote: > >> >>> Even if there are platforms which may change the CPU frequency behind >> >>> cpufreq's back, breaking the transition notifiers, I'm worried about the >> >>> addition of an interface which itself breaks them. The platforms which >> >>> do change CPU frequency on their own have probably evolved to live with >> >>> or work around this behavior. As other platforms migrate to fast >> >>> frequency switching they might be surprised when things don't work as >> >>> advertised. > > There's only 43 sites of cpufreq_register_notifier in 37 files, that > should be fairly simple to audit. > >> >>> I'm not sure what the easiest way to deal with this is. I see the >> >>> transition notifiers are the srcu type, which I understand to be >> >>> blocking. Going through the tree and reworking everyone's callbacks and >> >>> changing the type to atomic is obviously not realistic. >> >> >> >> Right. > > Even if it was (and per the above it looks entirely feasible), that's > just not going to happen. We're not ever going to call random notifier > crap from this deep within the scheduler. > >> >>> How about modifying cpufreq_register_notifier to return an error if the >> >>> driver has a fast_switch callback installed and an attempt to register a >> >>> transition notifier is made? >> >> >> >> That sounds like a good idea. > > Agreed, fail the stuff hard. > > Simply make cpufreq_register_notifier a __must_check function and add > error handling to all call sites. Quite frankly, I don't see a compelling reason to do anything about the notifications at this point. The ACPI driver is the only one that will support fast switching for the time being and on practically all platforms that can use the ACPI driver the transition notifications cannot be relied on anyway for a few reasons. First, if intel_pstate or HWP is in use, they won't be coming at all. Second, anything turbo will just change frequency at will without notifying (like HWP). Finally, if they are coming, whoever receives them is notified about the frequency that is requested and not the real one, which is misleading, because (a) the request may just make the CPU go into the turbo range and then see above or (b) if the CPU is in a platform-coordinated package, its request will only be granted if it's the winning one. >> > I guess what might be done would be to spawn a work item to carry out >> > a notify when the frequency changes. >> >> In fact, the mechanism may be relatively simple if I'm not mistaken. >> >> In the "fast switch" case, the governor may spawn a work item that >> will just execute cpufreq_get() on policy->cpu. That will notice that >> policy->cur is different from the real current frequency and will >> re-adjust. >> >> Of course, cpufreq_driver_fast_switch() will need to be modified so it >> doesn't update policy->cur then perhaps with a comment that the >> governor using it will be responsible for that. > > No no no, that's just horrible. Why would you want to keep this > notification stuff alive? If your platform can change frequency 'fast' > you don't want notifiers. I'm not totally sure about that. > > What's the point of a notification that says: "At some point in the > random past my frequency has changed, and it likely has changed again > since then, do 'something'." > > That's pointless. If you have dependent clock domains or whatever, you > simply _cannot_ be fast. > What about thermal? They don't need to get very accurate information, but they need to be updated on a regular basis. It would do if they get averages instead of momentary values (and may be better even).
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | linux.kernel
csiph-web