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


Groups > linux.kernel > #1610036

Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

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

Show all headers | View raw


[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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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