All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vikram Mulukutla <markivx@codeaurora.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Juri Lelli <juri.lelli@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	mingo@redhat.com, viresh.kumar@linaro.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	tglx@linutronix.de, vincent.guittot@linaro.org,
	rostedt@goodmis.org, luca.abeni@santannapisa.it,
	claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it,
	bristot@redhat.com, mathieu.poirier@linaro.org,
	tkjos@android.com, joelaf@google.com, andresoportus@google.com,
	morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
	patrick.bellasi@arm.com, Ingo Molnar <mingo@kernel.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Mark Brown <broonie@kernel.org>,
	linux-kernel-owner@vger.kernel.org
Subject: Re: [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE
Date: Thu, 30 Mar 2017 08:50:11 -0700	[thread overview]
Message-ID: <cfffdfdd5251ae7921f65d1e0360a289@codeaurora.org> (raw)
In-Reply-To: <1721120.3Th1GMboUn@aspire.rjw.lan>



> OK
> 
> So there are two pieces here.
> 
> One is that if we want *all* drivers to work with schedutil, we need to 
> keep
> the kthread for the ones that will never be reworked (because nobody 
> cares
> etc).  But then perhaps the kthread implementation may be left alone 
> (because
> nobody cares etc).
> 
> The second one is that there are drivers operating in-context that work 
> with
> schedutil already, so I don't see major obstacles to making more 
> drivers work
> that way.  That would be only a matter of reworking the drivers in 
> question.
> 
> Thanks,
> Rafael

There are some MSM platforms that do need a kthread and would love to 
use
schedutil. This is all mainly due to the point that Vincent raised; 
having
to actually wait for voltage transitions before clock switches. I can't
speak about the future, but that's the situation right now. Leaving the
kthread alone for now would be appreciated!

Thanks,
Vikram

  parent reply	other threads:[~2017-03-30 15:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 14:08 [RFD PATCH 0/5] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli
2017-03-24 14:08 ` [RFD PATCH 1/5] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli
2017-03-24 14:08 ` [RFD PATCH 2/5] sched/deadline: move cpu frequency selection triggering points Juri Lelli
2017-03-24 14:08 ` [RFD PATCH 3/5] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE Juri Lelli
2017-03-27 16:50   ` Peter Zijlstra
2017-03-27 17:01     ` Juri Lelli
2017-03-27 17:05       ` Rafael J. Wysocki
2017-03-27 17:13         ` Juri Lelli
2017-03-27 17:37           ` Rafael J. Wysocki
2017-03-27 18:09             ` Mark Brown
2017-03-30 15:50             ` Vikram Mulukutla [this message]
2017-03-30 20:22               ` Rafael J. Wysocki
2017-03-31  7:26                 ` Juri Lelli
2017-03-27 18:05     ` Mark Brown
2017-03-28  9:29     ` Vincent Guittot
2017-03-28  9:29       ` Vincent Guittot
2017-03-28 10:20       ` Peter Zijlstra
2017-03-28 10:20         ` Peter Zijlstra
2017-03-24 14:08 ` [RFD PATCH 4/5] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq Juri Lelli
2017-03-29 22:41   ` Rafael J. Wysocki
2017-03-30  8:58     ` Juri Lelli
2017-03-30 13:21       ` Vincent Guittot
2017-03-30 13:21         ` Vincent Guittot
2017-03-30 20:13       ` Rafael J. Wysocki
2017-03-30 20:13         ` Rafael J. Wysocki
2017-03-31  7:31         ` Juri Lelli
2017-03-31  7:31           ` Juri Lelli
2017-03-31  9:03           ` Rafael J. Wysocki
2017-03-31  9:03             ` Rafael J. Wysocki
2017-03-31  9:16             ` Juri Lelli
2017-03-31  9:16               ` Juri Lelli
2017-03-24 14:09 ` [RFD PATCH 5/5] sched/deadline: make bandwidth enforcement scale-invariant Juri Lelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cfffdfdd5251ae7921f65d1e0360a289@codeaurora.org \
    --to=markivx@codeaurora.org \
    --cc=andresoportus@google.com \
    --cc=bristot@redhat.com \
    --cc=broonie@kernel.org \
    --cc=claudio@evidence.eu.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel-owner@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tkjos@android.com \
    --cc=tommaso.cucinotta@santannapisa.it \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.