From: Arjan van de Ven <arjan@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>,
"mingo@kernel.org" <mingo@kernel.org>,
"pjt@google.com" <pjt@google.com>, "rjw@sisk.pl" <rjw@sisk.pl>,
"dirk.j.brandewie@intel.com" <dirk.j.brandewie@intel.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"alex.shi@linaro.org" <alex.shi@linaro.org>,
"preeti@linux.vnet.ibm.com" <preeti@linux.vnet.ibm.com>,
"efault@gmx.de" <efault@gmx.de>,
"corbet@lwn.net" <corbet@lwn.net>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>
Subject: Re: [RFC][PATCH 4/7] sched: power: Remove power capacity hints for kworker threads
Date: Thu, 17 Oct 2013 10:18:38 -0700 [thread overview]
Message-ID: <52601BEE.5090500@linux.intel.com> (raw)
In-Reply-To: <20131017165416.GW10651@twins.programming.kicks-ass.net>
>>
>> cpufreq has pre- and post-change notifiers so the current TC2 clock driver
yeah those are EVIL ;-)
>> waits (yields) in its clk_set_rate() implementation until the change has
>> happened to ensure that the post-change notifier happens at the right
>> time. Since clk_set_rate() is allowed to sleep other tasks may be
>> running while waiting for the change to complete. This may be true for
>> other clock drivers as well.
>>
>> AFAICT, there is no way to reuse the existing cpufreq drivers in a
>> sensible way for scheduler driven frequency scaling.
that's the conclusion we came to as well about a year ago (and is also
why we're no longer using cpufreq core for the Intel pstate driver.
the locking/sleeping/callback/cpuhotplug/sysfs/etc stuff is just a MESS
for something that ends up being extremely simple if you just code the
sequence... for us it's just one register write to change... which shows this as an
extreme obviously)
>
> Note that you still have preemption disabled in your late callback from
> finish_task_switch(). There's no way you can wait/yield/whatever from
> there. Nor is that really sane.
the other fun one with this could be that if you have a series of scheduleable tasks
for changing stuff.... somehow you want to keep ordering in the requests, and only do
the last one/etc.
Not Fun(tm)
next prev parent reply other threads:[~2013-10-17 17:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 17:19 [RFC][PATCH 0/7] Power-aware scheduling v2 Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 1/7] Initial power driver interface infrastructure Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 2/7] sched: power: Power driver late callback interface Morten Rasmussen
2013-10-14 13:42 ` Peter Zijlstra
2013-10-11 17:19 ` [RFC][PATCH 3/7] sched: power: go_faster/slower power driver hints Morten Rasmussen
2013-10-12 2:58 ` Michael wang
2013-10-14 12:42 ` Morten Rasmussen
2013-10-14 13:48 ` Peter Zijlstra
2013-10-14 15:55 ` Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 4/7] sched: power: Remove power capacity hints for kworker threads Morten Rasmussen
2013-10-14 13:33 ` Peter Zijlstra
2013-10-14 15:14 ` Arjan van de Ven
2013-10-17 16:40 ` Morten Rasmussen
2013-10-17 16:54 ` Peter Zijlstra
2013-10-17 17:18 ` Arjan van de Ven [this message]
2013-10-18 8:47 ` Morten Rasmussen
2013-10-18 13:43 ` Arjan van de Ven
2013-10-18 8:38 ` Morten Rasmussen
2013-10-14 16:10 ` Morten Rasmussen
2013-10-14 16:13 ` Arjan van de Ven
2013-10-14 17:19 ` Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 5/7] sched: power: Increase cpu capacity based on rq tracked load Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 6/7] sched: power: cpufreq: Initial schedpower cpufreq governor/power driver Morten Rasmussen
2013-10-11 17:19 ` [RFC][PATCH 7/7] sched: power: Let the power driver choose the best wake-up cpu Morten Rasmussen
2013-10-14 13:32 ` [RFC][PATCH 0/7] Power-aware scheduling v2 Peter Zijlstra
2013-10-14 17:15 ` Morten Rasmussen
2013-10-14 17:31 ` Peter Zijlstra
2013-10-15 17:05 ` Morten Rasmussen
2013-10-15 9:57 ` Preeti U Murthy
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=52601BEE.5090500@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=Catalin.Marinas@arm.com \
--cc=alex.shi@linaro.org \
--cc=corbet@lwn.net \
--cc=dirk.j.brandewie@intel.com \
--cc=efault@gmx.de \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=preeti@linux.vnet.ibm.com \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox