Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1610036
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE |
| Date | 2017-03-27 20:10 +0200 |
| Message-ID | <tpHfA-3EZ-17@gated-at.bofh.it> (permalink) |
| References | <toy4F-2Fu-9@gated-at.bofh.it> <toyeo-2LK-71@gated-at.bofh.it> <tpG9Q-2Hb-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Mon, Mar 27, 2017 at 06:50:11PM +0200, Peter Zijlstra wrote: > Taken together this seems to suggest we can rework cpufreq drivers to > function in-context, either directly push the packet on the bus if > available, or queue it and let whoever owns it sort it without blocking. Note that this isn't really cpufreq's problem per se, cpufreq is going to work out what voltage it wants then tell the regulator API to do that which will in turn go communicate with the PMIC somehow, typically with regmap over I2C or SPI. All those layers use mutexes by default. > So if we can make all that work, we can do away with this horrible > horrible kthread. Which is, IMO, a much better solution. > Thoughts? I think it's doable, but a lot of work especially in the regulator code.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFD PATCH 0/5] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:10 +0100
[RFD PATCH 2/5] sched/deadline: move cpu frequency selection triggering points Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:10 +0100
[RFD PATCH 5/5] sched/deadline: make bandwidth enforcement scale-invariant Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:20 +0100
[RFD PATCH 1/5] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:20 +0100
[RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:20 +0100
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Peter Zijlstra <peterz@infradead.org> - 2017-03-27 19:00 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli <juri.lelli@arm.com> - 2017-03-27 19:20 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-27 19:50 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Mark Brown <broonie@kernel.org> - 2017-03-27 20:20 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Vikram Mulukutla <markivx@codeaurora.org> - 2017-03-30 18:00 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-30 22:30 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli <juri.lelli@arm.com> - 2017-03-31 09:30 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli <juri.lelli@arm.com> - 2017-03-27 19:20 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-27 19:20 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Mark Brown <broonie@kernel.org> - 2017-03-27 20:10 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-28 11:40 +0200
Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Peter Zijlstra <peterz@infradead.org> - 2017-03-28 12:30 +0200
[RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-03-24 15:20 +0100
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-30 00:50 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-03-30 11:00 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-30 15:30 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-30 22:20 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-03-31 09:40 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-31 11:10 +0200
Re: [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli <juri.lelli@arm.com> - 2017-03-31 11:20 +0200
csiph-web