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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-07 09:10 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r9YoN-fN-5@gated-at.bofh.it> |
| In reply to | #1351026 |
On Sun, Mar 06, 2016 at 03:17:09AM +0100, Rafael J. Wysocki wrote: > > 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. Sure I know all that. But that, to me, seems like an argument for why you should have done this a long time ago. Someone registering a notifier you _know_ won't be called reliably is a sure sign of borkage. And you want to be notified (pun intended) of borkage. So the alternative option to making the registration fail, is making the registration WARN (and possibly disable fast support in the driver). But I do think something wants to be done here. > > 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. I am, per definition, if you need to call notifiers, you're not fast. I would really suggest making that a hard rule and enforcing it. > > 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). Thermal, should be an integral part of cpufreq, but if they need a callback from the switching hook (and here I would like to remind everyone that this is inside scheduler hot paths and the more code you stuff in the harder the performance regressions will hit you in the face) it can get a direct function call. No need for no stinking notifiers.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-07 14:20 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <ra3eP-3jo-15@gated-at.bofh.it> |
| In reply to | #1351365 |
On Mon, Mar 7, 2016 at 9:00 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Sun, Mar 06, 2016 at 03:17:09AM +0100, Rafael J. Wysocki wrote: >> > 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. > > Sure I know all that. But that, to me, seems like an argument for why > you should have done this a long time ago. While I generally agree with this, I don't quite see why cleaning that up necessarily has to be connected to the current patch series which is my point. > Someone registering a notifier you _know_ won't be called reliably is a > sure sign of borkage. And you want to be notified (pun intended) of > borkage. > > So the alternative option to making the registration fail, is making the > registration WARN (and possibly disable fast support in the driver). > > But I do think something wants to be done here. So here's what I can do for the "fast switch" thing. There is the fast_switch_possible policy flag that's necessary anyway. I can make notifier registration fail when that is set for at least one policy and I can make the setting of it fail if at least one notifier has already been registered. However, without spending too much time on chasing code dependencies i sort of suspect that it will uncover things that register cpufreq notifiers early and it won't be possible to use fast switch without sorting that out. And that won't even change anything apart from removing some code that has not worked for quite a while already and nobody noticed. >> > 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. > > I am, per definition, if you need to call notifiers, you're not fast. > > I would really suggest making that a hard rule and enforcing it. OK, but see above. It is doable for the "fast switch" thing, but it won't help in all of the other cases when notifications are not reliable. >> > 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). > > Thermal, should be an integral part of cpufreq, but if they need a > callback from the switching hook (and here I would like to remind > everyone that this is inside scheduler hot paths and the more code you > stuff in the harder the performance regressions will hit you in the > face) Calling notifiers (or any kind of callbacks that anyone can register) from there is out of the question. > it can get a direct function call. No need for no stinking > notifiers. I'm not talking about hooks in the switching code but *some* way to let stuff know about frequency changes. If it changes frequently enough, it's not practical and not even necessary to cause things like thermal to react on every change, but I think there needs to be a way to make them reevaluate things regularly. Arguably, they might set a timer for that, but why would they need a timer if they could get triggered by the code that actually makes changes?
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-07 14:40 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <ra3y9-3rb-9@gated-at.bofh.it> |
| In reply to | #1351603 |
On Mon, Mar 07, 2016 at 02:15:47PM +0100, Rafael J. Wysocki wrote: > On Mon, Mar 7, 2016 at 9:00 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > Sure I know all that. But that, to me, seems like an argument for why > > you should have done this a long time ago. > > While I generally agree with this, I don't quite see why cleaning that > up necessarily has to be connected to the current patch series which > is my point. Ah OK, fair enough I suppose. But someone should stick this on their TODO list, we should not 'forget' about this (again). > > But I do think something wants to be done here. > > So here's what I can do for the "fast switch" thing. > > There is the fast_switch_possible policy flag that's necessary anyway. > I can make notifier registration fail when that is set for at least > one policy and I can make the setting of it fail if at least one > notifier has already been registered. > > However, without spending too much time on chasing code dependencies i > sort of suspect that it will uncover things that register cpufreq > notifiers early and it won't be possible to use fast switch without > sorting that out. The two x86 users don't register notifiers when CONSTANT_TSC, which seems to be the right thing. Much of the other users seem unlikely to be used on x86, so I suspect the initial fallout will be very limited. *groan* modules, cpufreq allows drivers to be modules, so init sequences are poorly defined at best :/ Yes that blows. > And that won't even change anything apart from > removing some code that has not worked for quite a while already and > nobody noticed. Which is always a good thing, but yes, we can do this later. > It is doable for the "fast switch" thing, but it won't help in all of > the other cases when notifications are not reliable. Right, you can maybe add a 'NOTIFIERS_BROKEN' flag to the intel_p_state and HWP drivers or so, and trigger off of that. > If it changes frequently enough, it's not practical and not even > necessary to cause things like thermal to react on every change, but I > think there needs to be a way to make them reevaluate things > regularly. Arguably, they might set a timer for that, but why would > they need a timer if they could get triggered by the code that > actually makes changes? So that very much depends on what thermal actually needs; but I suspect that using a timer is cheaper than using irq_work to kick off something else. The irq_work is a LAPIC write (self IPI), just as the timer. However timers can be coalesced, resulting in, on average, less timer reprogramming than there are handlers ran. Now, if thermal can do without work and can run in-line just like the fast freq switch, then yes, that might make sense.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-07 14:50 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <ra3HP-3uq-9@gated-at.bofh.it> |
| In reply to | #1351606 |
On Mon, Mar 7, 2016 at 2:32 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Mon, Mar 07, 2016 at 02:15:47PM +0100, Rafael J. Wysocki wrote: >> On Mon, Mar 7, 2016 at 9:00 AM, Peter Zijlstra <peterz@infradead.org> wrote: > >> > Sure I know all that. But that, to me, seems like an argument for why >> > you should have done this a long time ago. >> >> While I generally agree with this, I don't quite see why cleaning that >> up necessarily has to be connected to the current patch series which >> is my point. > > Ah OK, fair enough I suppose. But someone should stick this on their > TODO list, we should not 'forget' about this (again). Sure. >> > But I do think something wants to be done here. >> >> So here's what I can do for the "fast switch" thing. >> >> There is the fast_switch_possible policy flag that's necessary anyway. >> I can make notifier registration fail when that is set for at least >> one policy and I can make the setting of it fail if at least one >> notifier has already been registered. >> >> However, without spending too much time on chasing code dependencies i >> sort of suspect that it will uncover things that register cpufreq >> notifiers early and it won't be possible to use fast switch without >> sorting that out. > > The two x86 users don't register notifiers when CONSTANT_TSC, which > seems to be the right thing. > > Much of the other users seem unlikely to be used on x86, so I suspect > the initial fallout will be very limited. OK, let me try this then. > *groan* modules, cpufreq allows drivers to be modules, so init sequences > are poorly defined at best :/ Yes that blows. Yup. >> And that won't even change anything apart from >> removing some code that has not worked for quite a while already and >> nobody noticed. > > Which is always a good thing, but yes, we can do this later. > >> It is doable for the "fast switch" thing, but it won't help in all of >> the other cases when notifications are not reliable. > > Right, you can maybe add a 'NOTIFIERS_BROKEN' flag to the intel_p_state > and HWP drivers or so, and trigger off of that. Something like that, yes.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-05 00:00 +0100 |
| Subject | Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching |
| Message-ID | <r96Rs-5oV-5@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.
Transition notifiers may be registered before the driver is
registered, so that won't help in all cases.
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-3@gated-at.bofh.it> |
| In reply to | #1350661 |
On 03/04/2016 02:58 PM, Rafael J. Wysocki wrote: >>> 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. > > Transition notifiers may be registered before the driver is > registered, so that won't help in all cases. Could that hole be closed by a similar check in cpufreq_register_driver()? I.e. if the transition_notifier list is not empty, fail to register the driver (if the driver has a fast_switch routine)? Or alternatively, the fast_switch routine is not installed. thanks, Steve
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 0/10] cpufreq: schedutil governor |
| Message-ID | <r8OKR-B1-3@gated-at.bofh.it> |
| In reply to | #1347699 |
On Wednesday, March 02, 2016 02:56:28 AM Rafael J. Wysocki wrote: > Hi, > > My previous intro message still applies somewhat, so here's a link: > > http://marc.info/?l=linux-pm&m=145609673008122&w=2 > > The executive summary of the motivation is that I wanted to do two things: > use the utilization data from the scheduler (it's passed to the governor > as aguments of update callbacks anyway) and make it possible to set > CPU frequency without involving process context (fast frequency switching). > > Both have been prototyped in the previous RFCs: > > https://patchwork.kernel.org/patch/8426691/ > https://patchwork.kernel.org/patch/8426741/ > [cut] > > Comments welcome. There were quite a few comments to address, so here's a new version. First off, my interpretation of what Ingo said earlier today (or yesterday depending on your time zone) is that he wants all of the code dealing with the util and max values to be located in kernel/sched/. I can understand the motivation here, although schedutil shares some amount of code with the other governors, so the dependency on cpufreq will still be there, even if the code goes to kernel/sched/. Nevertheless, I decided to make that change just to see how it would look like if not for anything else. To that end, I revived a patch I had before the first schedutil one to remove util/max from the cpufreq hooks [7/10], moved the scheduler-related code from drivers/cpufreq/cpufreq.c to kernel/sched/cpufreq.c (new file) on top of that [8/10] and reintroduced cpufreq_update_util() in a slightly different form [9/10]. I did it this way in case it turns out to be necessary to apply [7/10] and [8/10] for the time being and defer the rest to the next cycle. Apart from that, I changed the frequency selection formula in the new governor to next_freq = util * max_freq / max and it seems to work. That allowed the code to be simplified somewhat as I don't need the extra relation field in struct sugov_policy now (RELATION_L is used everywhere). Finally, I tried to address the bikeshed comment from Viresh about the "wrong" names of data types etc related to governor sysfs attributes handling. Hopefully, the new ones are better. There are small tweaks all over on top of that. Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <r8OKS-B1-7@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use the observation that cpufreq_update_util() is only called
by the scheduler with rq->lock held, so the callers of
cpufreq_set_update_util_data() can use synchronize_sched()
instead of synchronize_rcu() to wait for cpufreq_update_util()
to complete. Moreover, if they are updated to do that,
rcu_read_(un)lock() calls in cpufreq_update_util() might be
replaced with rcu_read_(un)lock_sched(), respectively, but
those aren't really necessary, because the scheduler calls
that function from RCU-sched read-side critical sections
already.
In addition to that, if cpufreq_set_update_util_data() checks
the func field in the struct update_util_data before setting
the per-CPU pointer to it, the data->func check may be dropped
from cpufreq_update_util() as well.
Make the above changes to reduce the overhead from
cpufreq_update_util() in the scheduler paths invoking it
and to make the cleanup after removing its callbacks less
heavy-weight somewhat.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Changes from the previous version:
- Use rcu_dereference_sched() in cpufreq_update_util().
---
drivers/cpufreq/cpufreq.c | 25 +++++++++++++++++--------
drivers/cpufreq/cpufreq_governor.c | 2 +-
drivers/cpufreq/intel_pstate.c | 4 ++--
3 files changed, 20 insertions(+), 11 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -77,12 +77,15 @@ static DEFINE_PER_CPU(struct update_util
* to call from cpufreq_update_util(). That function will be called from an RCU
* read-side critical section, so it must not sleep.
*
- * Callers must use RCU callbacks to free any memory that might be accessed
- * via the old update_util_data pointer or invoke synchronize_rcu() right after
- * this function to avoid use-after-free.
+ * Callers must use RCU-sched callbacks to free any memory that might be
+ * accessed via the old update_util_data pointer or invoke synchronize_sched()
+ * right after this function to avoid use-after-free.
*/
void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
{
+ if (WARN_ON(data && !data->func))
+ return;
+
rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
}
EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
@@ -95,18 +98,24 @@ EXPORT_SYMBOL_GPL(cpufreq_set_update_uti
*
* This function is called by the scheduler on every invocation of
* update_load_avg() on the CPU whose utilization is being updated.
+ *
+ * It can only be called from RCU-sched read-side critical sections.
*/
void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
{
struct update_util_data *data;
- rcu_read_lock();
+#ifdef CONFIG_LOCKDEP
+ WARN_ON(debug_locks && !rcu_read_lock_sched_held());
+#endif
- data = rcu_dereference(*this_cpu_ptr(&cpufreq_update_util_data));
- if (data && data->func)
+ data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
+ /*
+ * If this isn't inside of an RCU-sched read-side critical section, data
+ * may become NULL after the check below.
+ */
+ if (data)
data->func(data, time, util, max);
-
- rcu_read_unlock();
}
/* Flag to suspend/resume CPUFreq governors */
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -280,7 +280,7 @@ static inline void gov_clear_update_util
for_each_cpu(i, policy->cpus)
cpufreq_set_update_util_data(i, NULL);
- synchronize_rcu();
+ synchronize_sched();
}
static void gov_cancel_work(struct cpufreq_policy *policy)
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1174,7 +1174,7 @@ static void intel_pstate_stop_cpu(struct
pr_debug("intel_pstate: CPU %d exiting\n", cpu_num);
cpufreq_set_update_util_data(cpu_num, NULL);
- synchronize_rcu();
+ synchronize_sched();
if (hwp_active)
return;
@@ -1442,7 +1442,7 @@ out:
for_each_online_cpu(cpu) {
if (all_cpu_data[cpu]) {
cpufreq_set_update_util_data(cpu, NULL);
- synchronize_rcu();
+ synchronize_sched();
kfree(all_cpu_data[cpu]);
}
}
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-09 13:50 +0100 |
| Subject | Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <raLIS-7XZ-13@gated-at.bofh.it> |
| In reply to | #1349814 |
On Fri, Mar 04, 2016 at 03:58:22AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Use the observation that cpufreq_update_util() is only called
> by the scheduler with rq->lock held, so the callers of
> cpufreq_set_update_util_data() can use synchronize_sched()
> instead of synchronize_rcu() to wait for cpufreq_update_util()
> to complete. Moreover, if they are updated to do that,
> rcu_read_(un)lock() calls in cpufreq_update_util() might be
> replaced with rcu_read_(un)lock_sched(), respectively, but
> those aren't really necessary, because the scheduler calls
> that function from RCU-sched read-side critical sections
> already.
>
> In addition to that, if cpufreq_set_update_util_data() checks
> the func field in the struct update_util_data before setting
> the per-CPU pointer to it, the data->func check may be dropped
> from cpufreq_update_util() as well.
>
> Make the above changes to reduce the overhead from
> cpufreq_update_util() in the scheduler paths invoking it
> and to make the cleanup after removing its callbacks less
> heavy-weight somewhat.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>
> Changes from the previous version:
> - Use rcu_dereference_sched() in cpufreq_update_util().
Which I think also shows the WARN_ON I insisted upon is redundant.
In any case, I cannot object to reducing overhead, esp. as this whole
patch was suggested by me in the first place, so:
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
That said, how about the below? It avoids a function call.
Ideally the whole thing would be a single direct function call, but
because of the current situation with multiple governors we're stuck
with the indirect call :/
---
drivers/cpufreq/cpufreq.c | 30 +-----------------------------
include/linux/cpufreq.h | 33 +++++++++++++++++++++++++++------
2 files changed, 28 insertions(+), 35 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b6dd41824368..d594bf18cb02 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -65,7 +65,7 @@ static struct cpufreq_driver *cpufreq_driver;
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
-static DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
/**
* cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
@@ -90,34 +90,6 @@ void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
}
EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
-/**
- * cpufreq_update_util - Take a note about CPU utilization changes.
- * @time: Current time.
- * @util: Current utilization.
- * @max: Utilization ceiling.
- *
- * This function is called by the scheduler on every invocation of
- * update_load_avg() on the CPU whose utilization is being updated.
- *
- * It can only be called from RCU-sched read-side critical sections.
- */
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
-{
- struct update_util_data *data;
-
-#ifdef CONFIG_LOCKDEP
- WARN_ON(debug_locks && !rcu_read_lock_sched_held());
-#endif
-
- data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
- /*
- * If this isn't inside of an RCU-sched read-side critical section, data
- * may become NULL after the check below.
- */
- if (data)
- data->func(data, time, util, max);
-}
-
/* Flag to suspend/resume CPUFreq governors */
static bool cpufreq_suspended;
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 277024ff2289..62d2a1d623e9 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -146,7 +146,33 @@ static inline bool policy_is_shared(struct cpufreq_policy *policy)
extern struct kobject *cpufreq_global_kobject;
#ifdef CONFIG_CPU_FREQ
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
+
+struct update_util_data {
+ void (*func)(struct update_util_data *data,
+ u64 time, unsigned long util, unsigned long max);
+};
+
+DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+
+/**
+ * cpufreq_update_util - Take a note about CPU utilization changes.
+ * @time: Current time.
+ * @util: Current utilization.
+ * @max: Utilization ceiling.
+ *
+ * This function is called by the scheduler on every invocation of
+ * update_load_avg() on the CPU whose utilization is being updated.
+ *
+ * It can only be called from RCU-sched read-side critical sections.
+ */
+static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+{
+ struct update_util_data *data;
+
+ data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
+ if (data)
+ data->func(data, time, util, max);
+}
/**
* cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
@@ -169,11 +195,6 @@ static inline void cpufreq_trigger_update(u64 time)
cpufreq_update_util(time, ULONG_MAX, 0);
}
-struct update_util_data {
- void (*func)(struct update_util_data *data,
- u64 time, unsigned long util, unsigned long max);
-};
-
void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
unsigned int cpufreq_get(unsigned int cpu);
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-03-09 15:20 +0100 |
| Subject | Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <raN7Y-yK-21@gated-at.bofh.it> |
| In reply to | #1354090 |
On Wed, Mar 9, 2016 at 1:39 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Mar 04, 2016 at 03:58:22AM +0100, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> Use the observation that cpufreq_update_util() is only called >> by the scheduler with rq->lock held, so the callers of >> cpufreq_set_update_util_data() can use synchronize_sched() >> instead of synchronize_rcu() to wait for cpufreq_update_util() >> to complete. Moreover, if they are updated to do that, >> rcu_read_(un)lock() calls in cpufreq_update_util() might be >> replaced with rcu_read_(un)lock_sched(), respectively, but >> those aren't really necessary, because the scheduler calls >> that function from RCU-sched read-side critical sections >> already. >> >> In addition to that, if cpufreq_set_update_util_data() checks >> the func field in the struct update_util_data before setting >> the per-CPU pointer to it, the data->func check may be dropped >> from cpufreq_update_util() as well. >> >> Make the above changes to reduce the overhead from >> cpufreq_update_util() in the scheduler paths invoking it >> and to make the cleanup after removing its callbacks less >> heavy-weight somewhat. >> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> >> --- >> >> Changes from the previous version: >> - Use rcu_dereference_sched() in cpufreq_update_util(). > > Which I think also shows the WARN_ON I insisted upon is redundant. > > In any case, I cannot object to reducing overhead, esp. as this whole > patch was suggested by me in the first place, so: > > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Thanks! > That said, how about the below? It avoids a function call. That is fine by me. What about taking it a bit further, though, and moving the definition of cpufreq_update_util_data to somewhere under kernel/sched/ (like kernel/sched/cpufreq.c maybe)? Then, the whole static inline void cpufreq_update_util() definition can go into kernel/sched/sched.h (it doesn't have to be visible anywhere beyond kernel/sched/) and the only thing that needs to be exported to cpufreq will be a helper (or two), to set/clear the cpufreq_update_util_data pointers. I'll try to cut a patch doing that later today for illustration.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-09 16:30 +0100 |
| Subject | Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <raOdI-1eq-15@gated-at.bofh.it> |
| In reply to | #1354166 |
On Wed, Mar 09, 2016 at 03:17:48PM +0100, Rafael J. Wysocki wrote: > > That said, how about the below? It avoids a function call. > > That is fine by me. > > What about taking it a bit further, though, and moving the definition > of cpufreq_update_util_data to somewhere under kernel/sched/ (like > kernel/sched/cpufreq.c maybe)? > > Then, the whole static inline void cpufreq_update_util() definition > can go into kernel/sched/sched.h (it doesn't have to be visible > anywhere beyond kernel/sched/) and the only thing that needs to be > exported to cpufreq will be a helper (or two), to set/clear the > cpufreq_update_util_data pointers. > > I'll try to cut a patch doing that later today for illustration. Right, that's a blend with your second patch. Sure.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-09 22:40 +0100 |
| Subject | Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <raTZO-5nL-43@gated-at.bofh.it> |
| In reply to | #1354215 |
On Wednesday, March 09, 2016 04:29:34 PM Peter Zijlstra wrote:
> On Wed, Mar 09, 2016 at 03:17:48PM +0100, Rafael J. Wysocki wrote:
> > > That said, how about the below? It avoids a function call.
> >
> > That is fine by me.
> >
> > What about taking it a bit further, though, and moving the definition
> > of cpufreq_update_util_data to somewhere under kernel/sched/ (like
> > kernel/sched/cpufreq.c maybe)?
> >
> > Then, the whole static inline void cpufreq_update_util() definition
> > can go into kernel/sched/sched.h (it doesn't have to be visible
> > anywhere beyond kernel/sched/) and the only thing that needs to be
> > exported to cpufreq will be a helper (or two), to set/clear the
> > cpufreq_update_util_data pointers.
> >
> > I'll try to cut a patch doing that later today for illustration.
>
> Right, that's a blend with your second patch. Sure.
OK, patch below.
---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: [PATCH] cpufreq: Move scheduler-related code to the sched directory
Create cpufreq.c under kernel/sched/ and move the cpufreq code
related to the scheduler to that file and to sched.h.
Redefine cpufreq_update_util() as a static inline function to avoid
function calls at its call sites in the scheduler code (as suggested
by Peter Zijlstra).
Also move the definition of struct update_util_data and declaration
of cpufreq_set_update_util_data() from include/linux/cpufreq.h to
include/linux/sched.h.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/cpufreq/cpufreq.c | 53 -------------------------------------
drivers/cpufreq/cpufreq_governor.c | 1
include/linux/cpufreq.h | 34 -----------------------
include/linux/sched.h | 9 ++++++
kernel/sched/Makefile | 1
kernel/sched/cpufreq.c | 37 +++++++++++++++++++++++++
kernel/sched/sched.h | 49 +++++++++++++++++++++++++++++++++-
7 files changed, 96 insertions(+), 88 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -65,59 +65,6 @@ static struct cpufreq_driver *cpufreq_dr
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
-static DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
-
-/**
- * cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
- * @cpu: The CPU to set the pointer for.
- * @data: New pointer value.
- *
- * Set and publish the update_util_data pointer for the given CPU. That pointer
- * points to a struct update_util_data object containing a callback function
- * to call from cpufreq_update_util(). That function will be called from an RCU
- * read-side critical section, so it must not sleep.
- *
- * Callers must use RCU-sched callbacks to free any memory that might be
- * accessed via the old update_util_data pointer or invoke synchronize_sched()
- * right after this function to avoid use-after-free.
- */
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
-{
- if (WARN_ON(data && !data->func))
- return;
-
- rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
-}
-EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
-
-/**
- * cpufreq_update_util - Take a note about CPU utilization changes.
- * @time: Current time.
- * @util: Current utilization.
- * @max: Utilization ceiling.
- *
- * This function is called by the scheduler on every invocation of
- * update_load_avg() on the CPU whose utilization is being updated.
- *
- * It can only be called from RCU-sched read-side critical sections.
- */
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
-{
- struct update_util_data *data;
-
-#ifdef CONFIG_LOCKDEP
- WARN_ON(debug_locks && !rcu_read_lock_sched_held());
-#endif
-
- data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
- /*
- * If this isn't inside of an RCU-sched read-side critical section, data
- * may become NULL after the check below.
- */
- if (data)
- data->func(data, time, util, max);
-}
-
/* Flag to suspend/resume CPUFreq governors */
static bool cpufreq_suspended;
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -146,36 +146,6 @@ static inline bool policy_is_shared(stru
extern struct kobject *cpufreq_global_kobject;
#ifdef CONFIG_CPU_FREQ
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
-
-/**
- * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
- * @time: Current time.
- *
- * The way cpufreq is currently arranged requires it to evaluate the CPU
- * performance state (frequency/voltage) on a regular basis to prevent it from
- * being stuck in a completely inadequate performance level for too long.
- * That is not guaranteed to happen if the updates are only triggered from CFS,
- * though, because they may not be coming in if RT or deadline tasks are active
- * all the time (or there are RT and DL tasks only).
- *
- * As a workaround for that issue, this function is called by the RT and DL
- * sched classes to trigger extra cpufreq updates to prevent it from stalling,
- * but that really is a band-aid. Going forward it should be replaced with
- * solutions targeted more specifically at RT and DL tasks.
- */
-static inline void cpufreq_trigger_update(u64 time)
-{
- cpufreq_update_util(time, ULONG_MAX, 0);
-}
-
-struct update_util_data {
- void (*func)(struct update_util_data *data,
- u64 time, unsigned long util, unsigned long max);
-};
-
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
-
unsigned int cpufreq_get(unsigned int cpu);
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_quick_get_max(unsigned int cpu);
@@ -187,10 +157,6 @@ int cpufreq_update_policy(unsigned int c
bool have_governor_per_policy(void);
struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
#else
-static inline void cpufreq_update_util(u64 time, unsigned long util,
- unsigned long max) {}
-static inline void cpufreq_trigger_update(u64 time) {}
-
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
Index: linux-pm/kernel/sched/cpufreq.c
===================================================================
--- /dev/null
+++ linux-pm/kernel/sched/cpufreq.c
@@ -0,0 +1,37 @@
+/*
+ * Scheduler code and data structures related to cpufreq.
+ *
+ * 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 "sched.h"
+
+DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+
+/**
+ * cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
+ * @cpu: The CPU to set the pointer for.
+ * @data: New pointer value.
+ *
+ * Set and publish the update_util_data pointer for the given CPU. That pointer
+ * points to a struct update_util_data object containing a callback function
+ * to call from cpufreq_update_util(). That function will be called from an RCU
+ * read-side critical section, so it must not sleep.
+ *
+ * Callers must use RCU-sched callbacks to free any memory that might be
+ * accessed via the old update_util_data pointer or invoke synchronize_sched()
+ * right after this function to avoid use-after-free.
+ */
+void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
+{
+ if (WARN_ON(data && !data->func))
+ return;
+
+ rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
+}
+EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
Index: linux-pm/kernel/sched/sched.h
===================================================================
--- linux-pm.orig/kernel/sched/sched.h
+++ linux-pm/kernel/sched/sched.h
@@ -9,7 +9,6 @@
#include <linux/irq_work.h>
#include <linux/tick.h>
#include <linux/slab.h>
-#include <linux/cpufreq.h>
#include "cpupri.h"
#include "cpudeadline.h"
@@ -1739,3 +1738,51 @@ static inline u64 irq_time_read(int cpu)
}
#endif /* CONFIG_64BIT */
#endif /* CONFIG_IRQ_TIME_ACCOUNTING */
+
+#ifdef CONFIG_CPU_FREQ
+DECLARE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+
+/**
+ * cpufreq_update_util - Take a note about CPU utilization changes.
+ * @time: Current time.
+ * @util: Current utilization.
+ * @max: Utilization ceiling.
+ *
+ * This function is called by the scheduler on every invocation of
+ * update_load_avg() on the CPU whose utilization is being updated.
+ *
+ * It can only be called from RCU-sched read-side critical sections.
+ */
+static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+{
+ struct update_util_data *data;
+
+ data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
+ if (data)
+ data->func(data, time, util, max);
+}
+
+/**
+ * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
+ * @time: Current time.
+ *
+ * The way cpufreq is currently arranged requires it to evaluate the CPU
+ * performance state (frequency/voltage) on a regular basis to prevent it from
+ * being stuck in a completely inadequate performance level for too long.
+ * That is not guaranteed to happen if the updates are only triggered from CFS,
+ * though, because they may not be coming in if RT or deadline tasks are active
+ * all the time (or there are RT and DL tasks only).
+ *
+ * As a workaround for that issue, this function is called by the RT and DL
+ * sched classes to trigger extra cpufreq updates to prevent it from stalling,
+ * but that really is a band-aid. Going forward it should be replaced with
+ * solutions targeted more specifically at RT and DL tasks.
+ */
+static inline void cpufreq_trigger_update(u64 time)
+{
+ cpufreq_update_util(time, ULONG_MAX, 0);
+}
+#else
+static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned long max) {}
+static inline void cpufreq_trigger_update(u64 time) {}
+#endif /* CONFIG_CPU_FREQ */
Index: linux-pm/include/linux/sched.h
===================================================================
--- linux-pm.orig/include/linux/sched.h
+++ linux-pm/include/linux/sched.h
@@ -3207,4 +3207,13 @@ static inline unsigned long rlimit_max(u
return task_rlimit_max(current, limit);
}
+#ifdef CONFIG_CPU_FREQ
+struct update_util_data {
+ void (*func)(struct update_util_data *data,
+ u64 time, unsigned long util, unsigned long max);
+};
+
+void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
+#endif /* CONFIG_CPU_FREQ */
+
#endif
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -18,6 +18,7 @@
#include <linux/export.h>
#include <linux/kernel_stat.h>
+#include <linux/sched.h>
#include <linux/slab.h>
#include "cpufreq_governor.h"
Index: linux-pm/kernel/sched/Makefile
===================================================================
--- linux-pm.orig/kernel/sched/Makefile
+++ linux-pm/kernel/sched/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_SCHED_AUTOGROUP) += auto_gr
obj-$(CONFIG_SCHEDSTATS) += stats.o
obj-$(CONFIG_SCHED_DEBUG) += debug.o
obj-$(CONFIG_CGROUP_CPUACCT) += cpuacct.o
+obj-$(CONFIG_CPU_FREQ) += cpufreq.o
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-03-10 10:20 +0100 |
| Subject | Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit |
| Message-ID | <rb4Vc-4Jq-21@gated-at.bofh.it> |
| In reply to | #1354484 |
On Wed, Mar 09, 2016 at 10:35:02PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Subject: [PATCH] cpufreq: Move scheduler-related code to the sched directory > > Create cpufreq.c under kernel/sched/ and move the cpufreq code > related to the scheduler to that file and to sched.h. > > Redefine cpufreq_update_util() as a static inline function to avoid > function calls at its call sites in the scheduler code (as suggested > by Peter Zijlstra). > > Also move the definition of struct update_util_data and declaration > of cpufreq_set_update_util_data() from include/linux/cpufreq.h to > include/linux/sched.h. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > drivers/cpufreq/cpufreq.c | 53 ------------------------------------- > drivers/cpufreq/cpufreq_governor.c | 1 > include/linux/cpufreq.h | 34 ----------------------- > include/linux/sched.h | 9 ++++++ > kernel/sched/Makefile | 1 > kernel/sched/cpufreq.c | 37 +++++++++++++++++++++++++ > kernel/sched/sched.h | 49 +++++++++++++++++++++++++++++++++- > 7 files changed, 96 insertions(+), 88 deletions(-) Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 5/10] cpufreq: Move governor attribute set headers to cpufreq.h |
| Message-ID | <r8OKS-B1-11@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move definitions and function headers related to struct gov_attr_set
to include/linux/cpufreq.h so they can be used by (future) goverernors
located outside of drivers/cpufreq/.
No functional changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
New patch. Needed to move cpufreq_schedutil.c to kernel/sched/.
---
drivers/cpufreq/cpufreq_governor.h | 21 ---------------------
include/linux/cpufreq.h | 23 +++++++++++++++++++++++
2 files changed, 23 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -41,19 +41,6 @@
/* Ondemand Sampling types */
enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
-struct gov_attr_set {
- struct kobject kobj;
- struct list_head policy_list;
- struct mutex update_lock;
- int usage_count;
-};
-
-extern const struct sysfs_ops governor_sysfs_ops;
-
-void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head *list_node);
-void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head *list_node);
-unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head *list_node);
-
/*
* Abbreviations:
* dbs: used as a shortform for demand based switching It helps to keep variable
@@ -80,14 +67,6 @@ static inline struct dbs_data *to_dbs_da
return container_of(attr_set, struct dbs_data, attr_set);
}
-/* Governor's specific attributes */
-struct governor_attr {
- struct attribute attr;
- ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
- ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
- size_t count);
-};
-
#define gov_show_one(_gov, file_name) \
static ssize_t show_##file_name \
(struct gov_attr_set *attr_set, char *buf) \
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -462,6 +462,29 @@ void cpufreq_unregister_governor(struct
struct cpufreq_governor *cpufreq_default_governor(void);
struct cpufreq_governor *cpufreq_fallback_governor(void);
+/* Governor attribute set */
+struct gov_attr_set {
+ struct kobject kobj;
+ struct list_head policy_list;
+ struct mutex update_lock;
+ int usage_count;
+};
+
+/* sysfs ops for cpufreq governors */
+extern const struct sysfs_ops governor_sysfs_ops;
+
+void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head *list_node);
+void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head *list_node);
+unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head *list_node);
+
+/* Governor sysfs attribute */
+struct governor_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
+ ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
+ size_t count);
+};
+
/*********************************************************************
* FREQUENCY TABLE HELPERS *
*********************************************************************/
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2016-03-04 07:00 +0100 |
| Subject | Re: [PATCH v2 5/10] cpufreq: Move governor attribute set headers to cpufreq.h |
| Message-ID | <r8QWm-20V-15@gated-at.bofh.it> |
| In reply to | #1349815 |
On 04-03-16, 04:05, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Move definitions and function headers related to struct gov_attr_set > to include/linux/cpufreq.h so they can be used by (future) goverernors > located outside of drivers/cpufreq/. > > No functional changes. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > > New patch. Needed to move cpufreq_schedutil.c to kernel/sched/. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- viresh
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 2/10][Resend] cpufreq: acpi-cpufreq: Make read and write operations more efficient |
| Message-ID | <r8OKS-B1-15@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Setting a new CPU frequency and reading the current request value
in the ACPI cpufreq driver involves each at least two switch
instructions (there's more if the policy is shared). One of
them is present in drv_read/write() that prepares a command
structure and the other happens in subsequent do_drv_read/write()
when that structure is interpreted. However, all of those switches
may be avoided by using function pointers.
To that end, add two function pointers to struct acpi_cpufreq_data
to represent read and write operations on the frequency register
and set them up during policy intitialization to point to the pair
of routines suitable for the given processor (Intel/AMD MSR access
or I/O port access). Then, use those pointers in do_drv_read/write()
and modify drv_read/write() to prepare the command structure for
them without any checks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
No changes.
---
drivers/cpufreq/acpi-cpufreq.c | 208 ++++++++++++++++++-----------------------
1 file changed, 95 insertions(+), 113 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -70,6 +70,8 @@ struct acpi_cpufreq_data {
unsigned int cpu_feature;
unsigned int acpi_perf_cpu;
cpumask_var_t freqdomain_cpus;
+ void (*cpu_freq_write)(struct acpi_pct_register *reg, u32 val);
+ u32 (*cpu_freq_read)(struct acpi_pct_register *reg);
};
/* acpi_perf_data is a pointer to percpu data. */
@@ -243,125 +245,119 @@ static unsigned extract_freq(u32 val, st
}
}
-struct msr_addr {
- u32 reg;
-};
+u32 cpu_freq_read_intel(struct acpi_pct_register *not_used)
+{
+ u32 val, dummy;
-struct io_addr {
- u16 port;
- u8 bit_width;
-};
+ rdmsr(MSR_IA32_PERF_CTL, val, dummy);
+ return val;
+}
+
+void cpu_freq_write_intel(struct acpi_pct_register *not_used, u32 val)
+{
+ u32 lo, hi;
+
+ rdmsr(MSR_IA32_PERF_CTL, lo, hi);
+ lo = (lo & ~INTEL_MSR_RANGE) | (val & INTEL_MSR_RANGE);
+ wrmsr(MSR_IA32_PERF_CTL, lo, hi);
+}
+
+u32 cpu_freq_read_amd(struct acpi_pct_register *not_used)
+{
+ u32 val, dummy;
+
+ rdmsr(MSR_AMD_PERF_CTL, val, dummy);
+ return val;
+}
+
+void cpu_freq_write_amd(struct acpi_pct_register *not_used, u32 val)
+{
+ wrmsr(MSR_AMD_PERF_CTL, val, 0);
+}
+
+u32 cpu_freq_read_io(struct acpi_pct_register *reg)
+{
+ u32 val;
+
+ acpi_os_read_port(reg->address, &val, reg->bit_width);
+ return val;
+}
+
+void cpu_freq_write_io(struct acpi_pct_register *reg, u32 val)
+{
+ acpi_os_write_port(reg->address, val, reg->bit_width);
+}
struct drv_cmd {
- unsigned int type;
- const struct cpumask *mask;
- union {
- struct msr_addr msr;
- struct io_addr io;
- } addr;
+ struct acpi_pct_register *reg;
u32 val;
+ union {
+ void (*write)(struct acpi_pct_register *reg, u32 val);
+ u32 (*read)(struct acpi_pct_register *reg);
+ } func;
};
/* Called via smp_call_function_single(), on the target CPU */
static void do_drv_read(void *_cmd)
{
struct drv_cmd *cmd = _cmd;
- u32 h;
- switch (cmd->type) {
- case SYSTEM_INTEL_MSR_CAPABLE:
- case SYSTEM_AMD_MSR_CAPABLE:
- rdmsr(cmd->addr.msr.reg, cmd->val, h);
- break;
- case SYSTEM_IO_CAPABLE:
- acpi_os_read_port((acpi_io_address)cmd->addr.io.port,
- &cmd->val,
- (u32)cmd->addr.io.bit_width);
- break;
- default:
- break;
- }
+ cmd->val = cmd->func.read(cmd->reg);
}
-/* Called via smp_call_function_many(), on the target CPUs */
-static void do_drv_write(void *_cmd)
+static u32 drv_read(struct acpi_cpufreq_data *data, const struct cpumask *mask)
{
- struct drv_cmd *cmd = _cmd;
- u32 lo, hi;
+ struct acpi_processor_performance *perf = to_perf_data(data);
+ struct drv_cmd cmd = {
+ .reg = &perf->control_register,
+ .func.read = data->cpu_freq_read,
+ };
+ int err;
- switch (cmd->type) {
- case SYSTEM_INTEL_MSR_CAPABLE:
- rdmsr(cmd->addr.msr.reg, lo, hi);
- lo = (lo & ~INTEL_MSR_RANGE) | (cmd->val & INTEL_MSR_RANGE);
- wrmsr(cmd->addr.msr.reg, lo, hi);
- break;
- case SYSTEM_AMD_MSR_CAPABLE:
- wrmsr(cmd->addr.msr.reg, cmd->val, 0);
- break;
- case SYSTEM_IO_CAPABLE:
- acpi_os_write_port((acpi_io_address)cmd->addr.io.port,
- cmd->val,
- (u32)cmd->addr.io.bit_width);
- break;
- default:
- break;
- }
+ err = smp_call_function_any(mask, do_drv_read, &cmd, 1);
+ WARN_ON_ONCE(err); /* smp_call_function_any() was buggy? */
+ return cmd.val;
}
-static void drv_read(struct drv_cmd *cmd)
+/* Called via smp_call_function_many(), on the target CPUs */
+static void do_drv_write(void *_cmd)
{
- int err;
- cmd->val = 0;
+ struct drv_cmd *cmd = _cmd;
- err = smp_call_function_any(cmd->mask, do_drv_read, cmd, 1);
- WARN_ON_ONCE(err); /* smp_call_function_any() was buggy? */
+ cmd->func.write(cmd->reg, cmd->val);
}
-static void drv_write(struct drv_cmd *cmd)
+static void drv_write(struct acpi_cpufreq_data *data,
+ const struct cpumask *mask, u32 val)
{
+ struct acpi_processor_performance *perf = to_perf_data(data);
+ struct drv_cmd cmd = {
+ .reg = &perf->control_register,
+ .val = val,
+ .func.write = data->cpu_freq_write,
+ };
int this_cpu;
this_cpu = get_cpu();
- if (cpumask_test_cpu(this_cpu, cmd->mask))
- do_drv_write(cmd);
- smp_call_function_many(cmd->mask, do_drv_write, cmd, 1);
+ if (cpumask_test_cpu(this_cpu, mask))
+ do_drv_write(&cmd);
+
+ smp_call_function_many(mask, do_drv_write, &cmd, 1);
put_cpu();
}
-static u32
-get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *data)
+static u32 get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *data)
{
- struct acpi_processor_performance *perf;
- struct drv_cmd cmd;
+ u32 val;
if (unlikely(cpumask_empty(mask)))
return 0;
- switch (data->cpu_feature) {
- case SYSTEM_INTEL_MSR_CAPABLE:
- cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
- cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
- break;
- case SYSTEM_AMD_MSR_CAPABLE:
- cmd.type = SYSTEM_AMD_MSR_CAPABLE;
- cmd.addr.msr.reg = MSR_AMD_PERF_CTL;
- break;
- case SYSTEM_IO_CAPABLE:
- cmd.type = SYSTEM_IO_CAPABLE;
- perf = to_perf_data(data);
- cmd.addr.io.port = perf->control_register.address;
- cmd.addr.io.bit_width = perf->control_register.bit_width;
- break;
- default:
- return 0;
- }
-
- cmd.mask = mask;
- drv_read(&cmd);
+ val = drv_read(data, mask);
- pr_debug("get_cur_val = %u\n", cmd.val);
+ pr_debug("get_cur_val = %u\n", val);
- return cmd.val;
+ return val;
}
static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
@@ -416,7 +412,7 @@ static int acpi_cpufreq_target(struct cp
{
struct acpi_cpufreq_data *data = policy->driver_data;
struct acpi_processor_performance *perf;
- struct drv_cmd cmd;
+ const struct cpumask *mask;
unsigned int next_perf_state = 0; /* Index into perf table */
int result = 0;
@@ -438,37 +434,17 @@ static int acpi_cpufreq_target(struct cp
}
}
- switch (data->cpu_feature) {
- case SYSTEM_INTEL_MSR_CAPABLE:
- cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
- cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
- cmd.val = (u32) perf->states[next_perf_state].control;
- break;
- case SYSTEM_AMD_MSR_CAPABLE:
- cmd.type = SYSTEM_AMD_MSR_CAPABLE;
- cmd.addr.msr.reg = MSR_AMD_PERF_CTL;
- cmd.val = (u32) perf->states[next_perf_state].control;
- break;
- case SYSTEM_IO_CAPABLE:
- cmd.type = SYSTEM_IO_CAPABLE;
- cmd.addr.io.port = perf->control_register.address;
- cmd.addr.io.bit_width = perf->control_register.bit_width;
- cmd.val = (u32) perf->states[next_perf_state].control;
- break;
- default:
- return -ENODEV;
- }
-
- /* cpufreq holds the hotplug lock, so we are safe from here on */
- if (policy->shared_type != CPUFREQ_SHARED_TYPE_ANY)
- cmd.mask = policy->cpus;
- else
- cmd.mask = cpumask_of(policy->cpu);
+ /*
+ * The core won't allow CPUs to go away until the governor has been
+ * stopped, so we can rely on the stability of policy->cpus.
+ */
+ mask = policy->shared_type == CPUFREQ_SHARED_TYPE_ANY ?
+ cpumask_of(policy->cpu) : policy->cpus;
- drv_write(&cmd);
+ drv_write(data, mask, perf->states[next_perf_state].control);
if (acpi_pstate_strict) {
- if (!check_freqs(cmd.mask, data->freq_table[index].frequency,
+ if (!check_freqs(mask, data->freq_table[index].frequency,
data)) {
pr_debug("acpi_cpufreq_target failed (%d)\n",
policy->cpu);
@@ -738,15 +714,21 @@ static int acpi_cpufreq_cpu_init(struct
}
pr_debug("SYSTEM IO addr space\n");
data->cpu_feature = SYSTEM_IO_CAPABLE;
+ data->cpu_freq_read = cpu_freq_read_io;
+ data->cpu_freq_write = cpu_freq_write_io;
break;
case ACPI_ADR_SPACE_FIXED_HARDWARE:
pr_debug("HARDWARE addr space\n");
if (check_est_cpu(cpu)) {
data->cpu_feature = SYSTEM_INTEL_MSR_CAPABLE;
+ data->cpu_freq_read = cpu_freq_read_intel;
+ data->cpu_freq_write = cpu_freq_write_intel;
break;
}
if (check_amd_hwpstate_cpu(cpu)) {
data->cpu_feature = SYSTEM_AMD_MSR_CAPABLE;
+ data->cpu_freq_read = cpu_freq_read_amd;
+ data->cpu_freq_write = cpu_freq_write_amd;
break;
}
result = -ENODEV;
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 3/10] cpufreq: governor: New data type for management part of dbs_data |
| Message-ID | <r8OKS-B1-9@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In addition to fields representing governor tunables, struct dbs_data
contains some fields needed for the management of objects of that
type. As it turns out, that part of struct dbs_data may be shared
with (future) governors that won't use the common code used by
"ondemand" and "conservative", so move it to a separate struct type
and modify the code using struct dbs_data to follow.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Changes from the previous version:
- The new data type is called gov_attr_set now (instead of gov_tunables)
and some variable names etc have been changed to follow.
---
drivers/cpufreq/cpufreq_conservative.c | 25 +++++----
drivers/cpufreq/cpufreq_governor.c | 90 ++++++++++++++++++++-------------
drivers/cpufreq/cpufreq_governor.h | 35 +++++++-----
drivers/cpufreq/cpufreq_ondemand.c | 29 ++++++----
4 files changed, 107 insertions(+), 72 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -41,6 +41,13 @@
/* Ondemand Sampling types */
enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
+struct gov_attr_set {
+ struct kobject kobj;
+ struct list_head policy_list;
+ struct mutex update_lock;
+ int usage_count;
+};
+
/*
* Abbreviations:
* dbs: used as a shortform for demand based switching It helps to keep variable
@@ -52,7 +59,7 @@ enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
/* Governor demand based switching data (per-policy or global). */
struct dbs_data {
- int usage_count;
+ struct gov_attr_set attr_set;
void *tuners;
unsigned int min_sampling_rate;
unsigned int ignore_nice_load;
@@ -60,37 +67,35 @@ struct dbs_data {
unsigned int sampling_down_factor;
unsigned int up_threshold;
unsigned int io_is_busy;
-
- struct kobject kobj;
- struct list_head policy_dbs_list;
- /*
- * Protect concurrent updates to governor tunables from sysfs,
- * policy_dbs_list and usage_count.
- */
- struct mutex mutex;
};
+static inline struct dbs_data *to_dbs_data(struct gov_attr_set *attr_set)
+{
+ return container_of(attr_set, struct dbs_data, attr_set);
+}
+
/* Governor's specific attributes */
-struct dbs_data;
struct governor_attr {
struct attribute attr;
- ssize_t (*show)(struct dbs_data *dbs_data, char *buf);
- ssize_t (*store)(struct dbs_data *dbs_data, const char *buf,
+ ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
+ ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
size_t count);
};
#define gov_show_one(_gov, file_name) \
static ssize_t show_##file_name \
-(struct dbs_data *dbs_data, char *buf) \
+(struct gov_attr_set *attr_set, char *buf) \
{ \
+ struct dbs_data *dbs_data = to_dbs_data(attr_set); \
struct _gov##_dbs_tuners *tuners = dbs_data->tuners; \
return sprintf(buf, "%u\n", tuners->file_name); \
}
#define gov_show_one_common(file_name) \
static ssize_t show_##file_name \
-(struct dbs_data *dbs_data, char *buf) \
+(struct gov_attr_set *attr_set, char *buf) \
{ \
+ struct dbs_data *dbs_data = to_dbs_data(attr_set); \
return sprintf(buf, "%u\n", dbs_data->file_name); \
}
@@ -184,7 +189,7 @@ void od_register_powersave_bias_handler(
(struct cpufreq_policy *, unsigned int, unsigned int),
unsigned int powersave_bias);
void od_unregister_powersave_bias_handler(void);
-ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
+ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
size_t count);
void gov_update_cpu_data(struct dbs_data *dbs_data);
#endif /* _CPUFREQ_GOVERNOR_H */
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -43,9 +43,10 @@ static DEFINE_MUTEX(gov_dbs_data_mutex);
* This must be called with dbs_data->mutex held, otherwise traversing
* policy_dbs_list isn't safe.
*/
-ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
+ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
unsigned int rate;
int ret;
@@ -59,7 +60,7 @@ ssize_t store_sampling_rate(struct dbs_d
* We are operating under dbs_data->mutex and so the list and its
* entries can't be freed concurrently.
*/
- list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) {
+ list_for_each_entry(policy_dbs, &attr_set->policy_list, list) {
mutex_lock(&policy_dbs->timer_mutex);
/*
* On 32-bit architectures this may race with the
@@ -96,7 +97,7 @@ void gov_update_cpu_data(struct dbs_data
{
struct policy_dbs_info *policy_dbs;
- list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) {
+ list_for_each_entry(policy_dbs, &dbs_data->attr_set.policy_list, list) {
unsigned int j;
for_each_cpu(j, policy_dbs->policy->cpus) {
@@ -111,9 +112,9 @@ void gov_update_cpu_data(struct dbs_data
}
EXPORT_SYMBOL_GPL(gov_update_cpu_data);
-static inline struct dbs_data *to_dbs_data(struct kobject *kobj)
+static inline struct gov_attr_set *to_gov_attr_set(struct kobject *kobj)
{
- return container_of(kobj, struct dbs_data, kobj);
+ return container_of(kobj, struct gov_attr_set, kobj);
}
static inline struct governor_attr *to_gov_attr(struct attribute *attr)
@@ -124,25 +125,24 @@ static inline struct governor_attr *to_g
static ssize_t governor_show(struct kobject *kobj, struct attribute *attr,
char *buf)
{
- struct dbs_data *dbs_data = to_dbs_data(kobj);
struct governor_attr *gattr = to_gov_attr(attr);
- return gattr->show(dbs_data, buf);
+ return gattr->show(to_gov_attr_set(kobj), buf);
}
static ssize_t governor_store(struct kobject *kobj, struct attribute *attr,
const char *buf, size_t count)
{
- struct dbs_data *dbs_data = to_dbs_data(kobj);
+ struct gov_attr_set *attr_set = to_gov_attr_set(kobj);
struct governor_attr *gattr = to_gov_attr(attr);
int ret = -EBUSY;
- mutex_lock(&dbs_data->mutex);
+ mutex_lock(&attr_set->update_lock);
- if (dbs_data->usage_count)
- ret = gattr->store(dbs_data, buf, count);
+ if (attr_set->usage_count)
+ ret = gattr->store(attr_set, buf, count);
- mutex_unlock(&dbs_data->mutex);
+ mutex_unlock(&attr_set->update_lock);
return ret;
}
@@ -424,6 +424,41 @@ static void free_policy_dbs_info(struct
gov->free(policy_dbs);
}
+static void gov_attr_set_init(struct gov_attr_set *attr_set,
+ struct list_head *list_node)
+{
+ INIT_LIST_HEAD(&attr_set->policy_list);
+ mutex_init(&attr_set->update_lock);
+ attr_set->usage_count = 1;
+ list_add(list_node, &attr_set->policy_list);
+}
+
+static void gov_attr_set_get(struct gov_attr_set *attr_set,
+ struct list_head *list_node)
+{
+ mutex_lock(&attr_set->update_lock);
+ attr_set->usage_count++;
+ list_add(list_node, &attr_set->policy_list);
+ mutex_unlock(&attr_set->update_lock);
+}
+
+static unsigned int gov_attr_set_put(struct gov_attr_set *attr_set,
+ struct list_head *list_node)
+{
+ unsigned int count;
+
+ mutex_lock(&attr_set->update_lock);
+ list_del(list_node);
+ count = --attr_set->usage_count;
+ mutex_unlock(&attr_set->update_lock);
+ if (count)
+ return count;
+
+ kobject_put(&attr_set->kobj);
+ mutex_destroy(&attr_set->update_lock);
+ return 0;
+}
+
static int cpufreq_governor_init(struct cpufreq_policy *policy)
{
struct dbs_governor *gov = dbs_governor_of(policy);
@@ -452,10 +487,7 @@ static int cpufreq_governor_init(struct
policy_dbs->dbs_data = dbs_data;
policy->governor_data = policy_dbs;
- mutex_lock(&dbs_data->mutex);
- dbs_data->usage_count++;
- list_add(&policy_dbs->list, &dbs_data->policy_dbs_list);
- mutex_unlock(&dbs_data->mutex);
+ gov_attr_set_get(&dbs_data->attr_set, &policy_dbs->list);
goto out;
}
@@ -465,8 +497,7 @@ static int cpufreq_governor_init(struct
goto free_policy_dbs_info;
}
- INIT_LIST_HEAD(&dbs_data->policy_dbs_list);
- mutex_init(&dbs_data->mutex);
+ gov_attr_set_init(&dbs_data->attr_set, &policy_dbs->list);
ret = gov->init(dbs_data, !policy->governor->initialized);
if (ret)
@@ -486,14 +517,11 @@ static int cpufreq_governor_init(struct
if (!have_governor_per_policy())
gov->gdbs_data = dbs_data;
- policy->governor_data = policy_dbs;
-
policy_dbs->dbs_data = dbs_data;
- dbs_data->usage_count = 1;
- list_add(&policy_dbs->list, &dbs_data->policy_dbs_list);
+ policy->governor_data = policy_dbs;
gov->kobj_type.sysfs_ops = &governor_sysfs_ops;
- ret = kobject_init_and_add(&dbs_data->kobj, &gov->kobj_type,
+ ret = kobject_init_and_add(&dbs_data->attr_set.kobj, &gov->kobj_type,
get_governor_parent_kobj(policy),
"%s", gov->gov.name);
if (!ret)
@@ -522,29 +550,21 @@ static int cpufreq_governor_exit(struct
struct dbs_governor *gov = dbs_governor_of(policy);
struct policy_dbs_info *policy_dbs = policy->governor_data;
struct dbs_data *dbs_data = policy_dbs->dbs_data;
- int count;
+ unsigned int count;
/* Protect gov->gdbs_data against concurrent updates. */
mutex_lock(&gov_dbs_data_mutex);
- mutex_lock(&dbs_data->mutex);
- list_del(&policy_dbs->list);
- count = --dbs_data->usage_count;
- mutex_unlock(&dbs_data->mutex);
+ count = gov_attr_set_put(&dbs_data->attr_set, &policy_dbs->list);
- if (!count) {
- kobject_put(&dbs_data->kobj);
-
- policy->governor_data = NULL;
+ policy->governor_data = NULL;
+ if (!count) {
if (!have_governor_per_policy())
gov->gdbs_data = NULL;
gov->exit(dbs_data, policy->governor->initialized == 1);
- mutex_destroy(&dbs_data->mutex);
kfree(dbs_data);
- } else {
- policy->governor_data = NULL;
}
free_policy_dbs_info(policy_dbs, gov);
Index: linux-pm/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_ondemand.c
+++ linux-pm/drivers/cpufreq/cpufreq_ondemand.c
@@ -207,9 +207,10 @@ static unsigned int od_dbs_timer(struct
/************************** sysfs interface ************************/
static struct dbs_governor od_dbs_gov;
-static ssize_t store_io_is_busy(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_io_is_busy(struct gov_attr_set *attr_set, const char *buf,
+ size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
unsigned int input;
int ret;
@@ -224,9 +225,10 @@ static ssize_t store_io_is_busy(struct d
return count;
}
-static ssize_t store_up_threshold(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_up_threshold(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
unsigned int input;
int ret;
ret = sscanf(buf, "%u", &input);
@@ -240,9 +242,10 @@ static ssize_t store_up_threshold(struct
return count;
}
-static ssize_t store_sampling_down_factor(struct dbs_data *dbs_data,
- const char *buf, size_t count)
+static ssize_t store_sampling_down_factor(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs_info *policy_dbs;
unsigned int input;
int ret;
@@ -254,7 +257,7 @@ static ssize_t store_sampling_down_facto
dbs_data->sampling_down_factor = input;
/* Reset down sampling multiplier in case it was active */
- list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list) {
+ list_for_each_entry(policy_dbs, &attr_set->policy_list, list) {
/*
* Doing this without locking might lead to using different
* rate_mult values in od_update() and od_dbs_timer().
@@ -267,9 +270,10 @@ static ssize_t store_sampling_down_facto
return count;
}
-static ssize_t store_ignore_nice_load(struct dbs_data *dbs_data,
- const char *buf, size_t count)
+static ssize_t store_ignore_nice_load(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
unsigned int input;
int ret;
@@ -291,9 +295,10 @@ static ssize_t store_ignore_nice_load(st
return count;
}
-static ssize_t store_powersave_bias(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_powersave_bias(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct od_dbs_tuners *od_tuners = dbs_data->tuners;
struct policy_dbs_info *policy_dbs;
unsigned int input;
@@ -308,7 +313,7 @@ static ssize_t store_powersave_bias(stru
od_tuners->powersave_bias = input;
- list_for_each_entry(policy_dbs, &dbs_data->policy_dbs_list, list)
+ list_for_each_entry(policy_dbs, &attr_set->policy_list, list)
ondemand_powersave_bias_init(policy_dbs->policy);
return count;
Index: linux-pm/drivers/cpufreq/cpufreq_conservative.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_conservative.c
+++ linux-pm/drivers/cpufreq/cpufreq_conservative.c
@@ -129,9 +129,10 @@ static struct notifier_block cs_cpufreq_
/************************** sysfs interface ************************/
static struct dbs_governor cs_dbs_gov;
-static ssize_t store_sampling_down_factor(struct dbs_data *dbs_data,
- const char *buf, size_t count)
+static ssize_t store_sampling_down_factor(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
unsigned int input;
int ret;
ret = sscanf(buf, "%u", &input);
@@ -143,9 +144,10 @@ static ssize_t store_sampling_down_facto
return count;
}
-static ssize_t store_up_threshold(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_up_threshold(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
unsigned int input;
int ret;
@@ -158,9 +160,10 @@ static ssize_t store_up_threshold(struct
return count;
}
-static ssize_t store_down_threshold(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_down_threshold(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
unsigned int input;
int ret;
@@ -175,9 +178,10 @@ static ssize_t store_down_threshold(stru
return count;
}
-static ssize_t store_ignore_nice_load(struct dbs_data *dbs_data,
- const char *buf, size_t count)
+static ssize_t store_ignore_nice_load(struct gov_attr_set *attr_set,
+ const char *buf, size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
unsigned int input;
int ret;
@@ -199,9 +203,10 @@ static ssize_t store_ignore_nice_load(st
return count;
}
-static ssize_t store_freq_step(struct dbs_data *dbs_data, const char *buf,
- size_t count)
+static ssize_t store_freq_step(struct gov_attr_set *attr_set, const char *buf,
+ size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
unsigned int input;
int ret;
[toc] | [prev] | [next] | [standalone]
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Date | 2016-03-04 07:00 +0100 |
| Subject | Re: [PATCH v2 3/10] cpufreq: governor: New data type for management part of dbs_data |
| Message-ID | <r8QWl-20V-9@gated-at.bofh.it> |
| In reply to | #1349817 |
On 04-03-16, 04:01, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > In addition to fields representing governor tunables, struct dbs_data > contains some fields needed for the management of objects of that > type. As it turns out, that part of struct dbs_data may be shared > with (future) governors that won't use the common code used by > "ondemand" and "conservative", so move it to a separate struct type > and modify the code using struct dbs_data to follow. > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > --- > > Changes from the previous version: > - The new data type is called gov_attr_set now (instead of gov_tunables) > and some variable names etc have been changed to follow. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- viresh
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 7/10] cpufreq: Rework the scheduler hooks for triggering updates |
| Message-ID | <r8OKS-B1-13@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit fe7034338ba0 (cpufreq: Add mechanism for registering
utilization update callbacks) added cpufreq_update_util() to be
called by the scheduler (from the CFS part) on utilization updates.
The goal was to allow CFS to pass utilization information to cpufreq
and to trigger it to evaluate the frequency/voltage configuration
(P-state) of every CPU on a regular basis.
However, the last two arguments of that function are never used by
the current code, so CFS might simply call cpufreq_trigger_update()
instead of it (like the RT and DL sched classes).
For this reason, drop the last two arguments of cpufreq_update_util(),
rename it to cpufreq_trigger_update() and modify CFS to call it.
Moreover, since the utilization is not involved in that now, rename
data types, functions and variables related to cpufreq_trigger_update()
to reflect that (eg. struct update_util_data becomes struct
freq_update_hook and so on).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
New patch.
Not strictly necessary, but I like the new names better. :-)
---
drivers/cpufreq/cpufreq.c | 52 +++++++++++++++++++++----------------
drivers/cpufreq/cpufreq_governor.c | 25 ++++++++---------
drivers/cpufreq/cpufreq_governor.h | 2 -
drivers/cpufreq/intel_pstate.c | 15 ++++------
include/linux/cpufreq.h | 32 ++--------------------
kernel/sched/deadline.c | 2 -
kernel/sched/fair.c | 13 +--------
kernel/sched/rt.c | 2 -
8 files changed, 58 insertions(+), 85 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -65,57 +65,65 @@ static struct cpufreq_driver *cpufreq_dr
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
static DEFINE_RWLOCK(cpufreq_driver_lock);
-static DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
+static DEFINE_PER_CPU(struct freq_update_hook *, cpufreq_freq_update_hook);
/**
- * cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
+ * cpufreq_set_freq_update_hook - Populate the CPU's freq_update_hook pointer.
* @cpu: The CPU to set the pointer for.
- * @data: New pointer value.
+ * @hook: New pointer value.
*
- * Set and publish the update_util_data pointer for the given CPU. That pointer
- * points to a struct update_util_data object containing a callback function
- * to call from cpufreq_update_util(). That function will be called from an RCU
- * read-side critical section, so it must not sleep.
+ * Set and publish the freq_update_hook pointer for the given CPU. That pointer
+ * points to a struct freq_update_hook object containing a callback function
+ * to call from cpufreq_trigger_update(). That function will be called from
+ * an RCU read-side critical section, so it must not sleep.
*
* Callers must use RCU-sched callbacks to free any memory that might be
* accessed via the old update_util_data pointer or invoke synchronize_sched()
* right after this function to avoid use-after-free.
*/
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
+void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook *hook)
{
- if (WARN_ON(data && !data->func))
+ if (WARN_ON(hook && !hook->func))
return;
- rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
+ rcu_assign_pointer(per_cpu(cpufreq_freq_update_hook, cpu), hook);
}
-EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
+EXPORT_SYMBOL_GPL(cpufreq_set_freq_update_hook);
/**
- * cpufreq_update_util - Take a note about CPU utilization changes.
+ * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
* @time: Current time.
- * @util: Current utilization.
- * @max: Utilization ceiling.
*
- * This function is called by the scheduler on every invocation of
- * update_load_avg() on the CPU whose utilization is being updated.
+ * The way cpufreq is currently arranged requires it to evaluate the CPU
+ * performance state (frequency/voltage) on a regular basis. To facilitate
+ * that, this function is called by update_load_avg() in CFS when executed for
+ * the current CPU's runqueue.
*
- * It can only be called from RCU-sched read-side critical sections.
+ * However, this isn't sufficient to prevent the CPU from being stuck in a
+ * completely inadequate performance level for too long, because the calls
+ * from CFS will not be made if RT or deadline tasks are active all the time
+ * (or there are RT and DL tasks only).
+ *
+ * As a workaround for that issue, this function is called by the RT and DL
+ * sched classes to trigger extra cpufreq updates to prevent it from stalling,
+ * but that really is a band-aid. Going forward it should be replaced with
+ * solutions targeted more specifically at RT and DL tasks.
*/
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
+void cpufreq_trigger_update(u64 time)
{
- struct update_util_data *data;
+ struct freq_update_hook *hook;
#ifdef CONFIG_LOCKDEP
WARN_ON(debug_locks && !rcu_read_lock_sched_held());
#endif
- data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
+ hook = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_freq_update_hook));
/*
* If this isn't inside of an RCU-sched read-side critical section, data
* may become NULL after the check below.
*/
- if (data)
- data->func(data, time, util, max);
+ if (hook)
+ hook->func(hook, time);
}
/* Flag to suspend/resume CPUFreq governors */
Index: linux-pm/include/linux/cpufreq.h
===================================================================
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -146,35 +146,13 @@ static inline bool policy_is_shared(stru
extern struct kobject *cpufreq_global_kobject;
#ifdef CONFIG_CPU_FREQ
-void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
+void cpufreq_trigger_update(u64 time);
-/**
- * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
- * @time: Current time.
- *
- * The way cpufreq is currently arranged requires it to evaluate the CPU
- * performance state (frequency/voltage) on a regular basis to prevent it from
- * being stuck in a completely inadequate performance level for too long.
- * That is not guaranteed to happen if the updates are only triggered from CFS,
- * though, because they may not be coming in if RT or deadline tasks are active
- * all the time (or there are RT and DL tasks only).
- *
- * As a workaround for that issue, this function is called by the RT and DL
- * sched classes to trigger extra cpufreq updates to prevent it from stalling,
- * but that really is a band-aid. Going forward it should be replaced with
- * solutions targeted more specifically at RT and DL tasks.
- */
-static inline void cpufreq_trigger_update(u64 time)
-{
- cpufreq_update_util(time, ULONG_MAX, 0);
-}
-
-struct update_util_data {
- void (*func)(struct update_util_data *data,
- u64 time, unsigned long util, unsigned long max);
+struct freq_update_hook {
+ void (*func)(struct freq_update_hook *hook, u64 time);
};
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
+void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook *hook);
unsigned int cpufreq_get(unsigned int cpu);
unsigned int cpufreq_quick_get(unsigned int cpu);
@@ -187,8 +165,6 @@ int cpufreq_update_policy(unsigned int c
bool have_governor_per_policy(void);
struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
#else
-static inline void cpufreq_update_util(u64 time, unsigned long util,
- unsigned long max) {}
static inline void cpufreq_trigger_update(u64 time) {}
static inline unsigned int cpufreq_get(unsigned int cpu)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -62,10 +62,10 @@ ssize_t store_sampling_rate(struct dbs_d
mutex_lock(&policy_dbs->timer_mutex);
/*
* On 32-bit architectures this may race with the
- * sample_delay_ns read in dbs_update_util_handler(), but that
+ * sample_delay_ns read in dbs_freq_update_handler(), but that
* really doesn't matter. If the read returns a value that's
* too big, the sample will be skipped, but the next invocation
- * of dbs_update_util_handler() (when the update has been
+ * of dbs_freq_update_handler() (when the update has been
* completed) will take a sample.
*
* If this runs in parallel with dbs_work_handler(), we may end
@@ -257,7 +257,7 @@ unsigned int dbs_update(struct cpufreq_p
}
EXPORT_SYMBOL_GPL(dbs_update);
-static void gov_set_update_util(struct policy_dbs_info *policy_dbs,
+static void gov_set_freq_update_hooks(struct policy_dbs_info *policy_dbs,
unsigned int delay_us)
{
struct cpufreq_policy *policy = policy_dbs->policy;
@@ -269,16 +269,16 @@ static void gov_set_update_util(struct p
for_each_cpu(cpu, policy->cpus) {
struct cpu_dbs_info *cdbs = &per_cpu(cpu_dbs, cpu);
- cpufreq_set_update_util_data(cpu, &cdbs->update_util);
+ cpufreq_set_freq_update_hook(cpu, &cdbs->update_hook);
}
}
-static inline void gov_clear_update_util(struct cpufreq_policy *policy)
+static inline void gov_clear_freq_update_hooks(struct cpufreq_policy *policy)
{
int i;
for_each_cpu(i, policy->cpus)
- cpufreq_set_update_util_data(i, NULL);
+ cpufreq_set_freq_update_hook(i, NULL);
synchronize_sched();
}
@@ -287,7 +287,7 @@ static void gov_cancel_work(struct cpufr
{
struct policy_dbs_info *policy_dbs = policy->governor_data;
- gov_clear_update_util(policy_dbs->policy);
+ gov_clear_freq_update_hooks(policy_dbs->policy);
irq_work_sync(&policy_dbs->irq_work);
cancel_work_sync(&policy_dbs->work);
atomic_set(&policy_dbs->work_count, 0);
@@ -331,10 +331,9 @@ static void dbs_irq_work(struct irq_work
schedule_work(&policy_dbs->work);
}
-static void dbs_update_util_handler(struct update_util_data *data, u64 time,
- unsigned long util, unsigned long max)
+static void dbs_freq_update_handler(struct freq_update_hook *hook, u64 time)
{
- struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info, update_util);
+ struct cpu_dbs_info *cdbs = container_of(hook, struct cpu_dbs_info, update_hook);
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
u64 delta_ns, lst;
@@ -403,7 +402,7 @@ static struct policy_dbs_info *alloc_pol
struct cpu_dbs_info *j_cdbs = &per_cpu(cpu_dbs, j);
j_cdbs->policy_dbs = policy_dbs;
- j_cdbs->update_util.func = dbs_update_util_handler;
+ j_cdbs->update_hook.func = dbs_freq_update_handler;
}
return policy_dbs;
}
@@ -419,7 +418,7 @@ static void free_policy_dbs_info(struct
struct cpu_dbs_info *j_cdbs = &per_cpu(cpu_dbs, j);
j_cdbs->policy_dbs = NULL;
- j_cdbs->update_util.func = NULL;
+ j_cdbs->update_hook.func = NULL;
}
gov->free(policy_dbs);
}
@@ -586,7 +585,7 @@ static int cpufreq_governor_start(struct
gov->start(policy);
- gov_set_update_util(policy_dbs, sampling_rate);
+ gov_set_freq_update_hooks(policy_dbs, sampling_rate);
return 0;
}
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -144,7 +144,7 @@ struct cpu_dbs_info {
* wake-up from idle.
*/
unsigned int prev_load;
- struct update_util_data update_util;
+ struct freq_update_hook update_hook;
struct policy_dbs_info *policy_dbs;
};
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -103,7 +103,7 @@ struct _pid {
struct cpudata {
int cpu;
- struct update_util_data update_util;
+ struct freq_update_hook update_hook;
struct pstate_data pstate;
struct vid_data vid;
@@ -1019,10 +1019,9 @@ static inline void intel_pstate_adjust_b
sample->freq);
}
-static void intel_pstate_update_util(struct update_util_data *data, u64 time,
- unsigned long util, unsigned long max)
+static void intel_pstate_freq_update(struct freq_update_hook *hook, u64 time)
{
- struct cpudata *cpu = container_of(data, struct cpudata, update_util);
+ struct cpudata *cpu = container_of(hook, struct cpudata, update_hook);
u64 delta_ns = time - cpu->sample.time;
if ((s64)delta_ns >= pid_params.sample_rate_ns) {
@@ -1088,8 +1087,8 @@ static int intel_pstate_init_cpu(unsigne
intel_pstate_busy_pid_reset(cpu);
intel_pstate_sample(cpu, 0);
- cpu->update_util.func = intel_pstate_update_util;
- cpufreq_set_update_util_data(cpunum, &cpu->update_util);
+ cpu->update_hook.func = intel_pstate_freq_update;
+ cpufreq_set_freq_update_hook(cpunum, &cpu->update_hook);
pr_debug("intel_pstate: controlling: cpu %d\n", cpunum);
@@ -1173,7 +1172,7 @@ static void intel_pstate_stop_cpu(struct
pr_debug("intel_pstate: CPU %d exiting\n", cpu_num);
- cpufreq_set_update_util_data(cpu_num, NULL);
+ cpufreq_set_freq_update_hook(cpu_num, NULL);
synchronize_sched();
if (hwp_active)
@@ -1441,7 +1440,7 @@ out:
get_online_cpus();
for_each_online_cpu(cpu) {
if (all_cpu_data[cpu]) {
- cpufreq_set_update_util_data(cpu, NULL);
+ cpufreq_set_freq_update_hook(cpu, NULL);
synchronize_sched();
kfree(all_cpu_data[cpu]);
}
Index: linux-pm/kernel/sched/fair.c
===================================================================
--- linux-pm.orig/kernel/sched/fair.c
+++ linux-pm/kernel/sched/fair.c
@@ -2839,8 +2839,6 @@ static inline void update_load_avg(struc
update_tg_load_avg(cfs_rq, 0);
if (cpu == smp_processor_id() && &rq->cfs == cfs_rq) {
- unsigned long max = rq->cpu_capacity_orig;
-
/*
* There are a few boundary cases this might miss but it should
* get called often enough that that should (hopefully) not be
@@ -2849,16 +2847,9 @@ static inline void update_load_avg(struc
* the next tick/schedule should update.
*
* It will not get called when we go idle, because the idle
- * thread is a different class (!fair), nor will the utilization
- * number include things like RT tasks.
- *
- * As is, the util number is not freq-invariant (we'd have to
- * implement arch_scale_freq_capacity() for that).
- *
- * See cpu_util().
+ * thread is a different class (!fair).
*/
- cpufreq_update_util(rq_clock(rq),
- min(cfs_rq->avg.util_avg, max), max);
+ cpufreq_trigger_update(rq_clock(rq));
}
}
Index: linux-pm/kernel/sched/deadline.c
===================================================================
--- linux-pm.orig/kernel/sched/deadline.c
+++ linux-pm/kernel/sched/deadline.c
@@ -726,7 +726,7 @@ static void update_curr_dl(struct rq *rq
if (!dl_task(curr) || !on_dl_rq(dl_se))
return;
- /* Kick cpufreq (see the comment in linux/cpufreq.h). */
+ /* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
if (cpu_of(rq) == smp_processor_id())
cpufreq_trigger_update(rq_clock(rq));
Index: linux-pm/kernel/sched/rt.c
===================================================================
--- linux-pm.orig/kernel/sched/rt.c
+++ linux-pm/kernel/sched/rt.c
@@ -945,7 +945,7 @@ static void update_curr_rt(struct rq *rq
if (curr->sched_class != &rt_sched_class)
return;
- /* Kick cpufreq (see the comment in linux/cpufreq.h). */
+ /* Kick cpufreq (see the comment in drivers/cpufreq/cpufreq.c). */
if (cpu_of(rq) == smp_processor_id())
cpufreq_trigger_update(rq_clock(rq));
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2016-03-04 04:40 +0100 |
| Subject | [PATCH v2 4/10] cpufreq: governor: Move abstract gov_attr_set code to seperate file |
| Message-ID | <r8OKS-B1-17@gated-at.bofh.it> |
| In reply to | #1349813 |
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move abstract code related to struct gov_attr_set to a separate (new)
file so it can be shared with (future) goverernors that won't share
more code with "ondemand" and "conservative".
No intentional functional changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Changes from the previous version:
- Different name of the new file.
- Different name of the new Kconfig symbol.
---
drivers/cpufreq/Kconfig | 4 +
drivers/cpufreq/Makefile | 1
drivers/cpufreq/cpufreq_governor.c | 82 ---------------------------
drivers/cpufreq/cpufreq_governor.h | 6 ++
drivers/cpufreq/cpufreq_governor_attr_set.c | 84 ++++++++++++++++++++++++++++
5 files changed, 95 insertions(+), 82 deletions(-)
Index: linux-pm/drivers/cpufreq/Kconfig
===================================================================
--- linux-pm.orig/drivers/cpufreq/Kconfig
+++ linux-pm/drivers/cpufreq/Kconfig
@@ -18,7 +18,11 @@ config CPU_FREQ
if CPU_FREQ
+config CPU_FREQ_GOV_ATTR_SET
+ bool
+
config CPU_FREQ_GOV_COMMON
+ select CPU_FREQ_GOV_ATTR_SET
select IRQ_WORK
bool
Index: linux-pm/drivers/cpufreq/Makefile
===================================================================
--- linux-pm.orig/drivers/cpufreq/Makefile
+++ linux-pm/drivers/cpufreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) +=
obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o
obj-$(CONFIG_CPU_FREQ_GOV_COMMON) += cpufreq_governor.o
+obj-$(CONFIG_CPU_FREQ_GOV_ATTR_SET) += cpufreq_governor_attr_set.o
obj-$(CONFIG_CPUFREQ_DT) += cpufreq-dt.o
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -112,53 +112,6 @@ void gov_update_cpu_data(struct dbs_data
}
EXPORT_SYMBOL_GPL(gov_update_cpu_data);
-static inline struct gov_attr_set *to_gov_attr_set(struct kobject *kobj)
-{
- return container_of(kobj, struct gov_attr_set, kobj);
-}
-
-static inline struct governor_attr *to_gov_attr(struct attribute *attr)
-{
- return container_of(attr, struct governor_attr, attr);
-}
-
-static ssize_t governor_show(struct kobject *kobj, struct attribute *attr,
- char *buf)
-{
- struct governor_attr *gattr = to_gov_attr(attr);
-
- return gattr->show(to_gov_attr_set(kobj), buf);
-}
-
-static ssize_t governor_store(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
-{
- struct gov_attr_set *attr_set = to_gov_attr_set(kobj);
- struct governor_attr *gattr = to_gov_attr(attr);
- int ret = -EBUSY;
-
- mutex_lock(&attr_set->update_lock);
-
- if (attr_set->usage_count)
- ret = gattr->store(attr_set, buf, count);
-
- mutex_unlock(&attr_set->update_lock);
-
- return ret;
-}
-
-/*
- * Sysfs Ops for accessing governor attributes.
- *
- * All show/store invocations for governor specific sysfs attributes, will first
- * call the below show/store callbacks and the attribute specific callback will
- * be called from within it.
- */
-static const struct sysfs_ops governor_sysfs_ops = {
- .show = governor_show,
- .store = governor_store,
-};
-
unsigned int dbs_update(struct cpufreq_policy *policy)
{
struct policy_dbs_info *policy_dbs = policy->governor_data;
@@ -424,41 +377,6 @@ static void free_policy_dbs_info(struct
gov->free(policy_dbs);
}
-static void gov_attr_set_init(struct gov_attr_set *attr_set,
- struct list_head *list_node)
-{
- INIT_LIST_HEAD(&attr_set->policy_list);
- mutex_init(&attr_set->update_lock);
- attr_set->usage_count = 1;
- list_add(list_node, &attr_set->policy_list);
-}
-
-static void gov_attr_set_get(struct gov_attr_set *attr_set,
- struct list_head *list_node)
-{
- mutex_lock(&attr_set->update_lock);
- attr_set->usage_count++;
- list_add(list_node, &attr_set->policy_list);
- mutex_unlock(&attr_set->update_lock);
-}
-
-static unsigned int gov_attr_set_put(struct gov_attr_set *attr_set,
- struct list_head *list_node)
-{
- unsigned int count;
-
- mutex_lock(&attr_set->update_lock);
- list_del(list_node);
- count = --attr_set->usage_count;
- mutex_unlock(&attr_set->update_lock);
- if (count)
- return count;
-
- kobject_put(&attr_set->kobj);
- mutex_destroy(&attr_set->update_lock);
- return 0;
-}
-
static int cpufreq_governor_init(struct cpufreq_policy *policy)
{
struct dbs_governor *gov = dbs_governor_of(policy);
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -48,6 +48,12 @@ struct gov_attr_set {
int usage_count;
};
+extern const struct sysfs_ops governor_sysfs_ops;
+
+void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head *list_node);
+void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head *list_node);
+unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head *list_node);
+
/*
* Abbreviations:
* dbs: used as a shortform for demand based switching It helps to keep variable
Index: linux-pm/drivers/cpufreq/cpufreq_governor_attr_set.c
===================================================================
--- /dev/null
+++ linux-pm/drivers/cpufreq/cpufreq_governor_attr_set.c
@@ -0,0 +1,84 @@
+/*
+ * Abstract code for CPUFreq governor tunable sysfs attributes.
+ *
+ * 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 "cpufreq_governor.h"
+
+static inline struct gov_attr_set *to_gov_attr_set(struct kobject *kobj)
+{
+ return container_of(kobj, struct gov_attr_set, kobj);
+}
+
+static inline struct governor_attr *to_gov_attr(struct attribute *attr)
+{
+ return container_of(attr, struct governor_attr, attr);
+}
+
+static ssize_t governor_show(struct kobject *kobj, struct attribute *attr,
+ char *buf)
+{
+ struct governor_attr *gattr = to_gov_attr(attr);
+
+ return gattr->show(to_gov_attr_set(kobj), buf);
+}
+
+static ssize_t governor_store(struct kobject *kobj, struct attribute *attr,
+ const char *buf, size_t count)
+{
+ struct gov_attr_set *attr_set = to_gov_attr_set(kobj);
+ struct governor_attr *gattr = to_gov_attr(attr);
+ int ret;
+
+ mutex_lock(&attr_set->update_lock);
+ ret = attr_set->usage_count ? gattr->store(attr_set, buf, count) : -EBUSY;
+ mutex_unlock(&attr_set->update_lock);
+ return ret;
+}
+
+const struct sysfs_ops governor_sysfs_ops = {
+ .show = governor_show,
+ .store = governor_store,
+};
+EXPORT_SYMBOL_GPL(governor_sysfs_ops);
+
+void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head *list_node)
+{
+ INIT_LIST_HEAD(&attr_set->policy_list);
+ mutex_init(&attr_set->update_lock);
+ attr_set->usage_count = 1;
+ list_add(list_node, &attr_set->policy_list);
+}
+EXPORT_SYMBOL_GPL(gov_attr_set_init);
+
+void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head *list_node)
+{
+ mutex_lock(&attr_set->update_lock);
+ attr_set->usage_count++;
+ list_add(list_node, &attr_set->policy_list);
+ mutex_unlock(&attr_set->update_lock);
+}
+EXPORT_SYMBOL_GPL(gov_attr_set_get);
+
+unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head *list_node)
+{
+ unsigned int count;
+
+ mutex_lock(&attr_set->update_lock);
+ list_del(list_node);
+ count = --attr_set->usage_count;
+ mutex_unlock(&attr_set->update_lock);
+ if (count)
+ return count;
+
+ kobject_put(&attr_set->kobj);
+ mutex_destroy(&attr_set->update_lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gov_attr_set_put);
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | linux.kernel
csiph-web