From: Peter Zijlstra <peterz@infradead.org>
To: Yuyang Du <yuyang.du@intel.com>
Cc: mingo@redhat.com, rafael.j.wysocki@intel.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
arjan.van.de.ven@intel.com, len.brown@intel.com,
alan.cox@intel.com, mark.gross@intel.com,
morten.rasmussen@arm.com, vincent.guittot@linaro.org,
rajeev.d.muralidhar@intel.com, vishwesh.m.rudramuni@intel.com,
nicole.chalhoub@intel.com, ajaya.durg@intel.com,
harinarayanan.seshadri@intel.com
Subject: Re: [RFC PATCH 00/12 v1] A new CPU load metric for power-efficient scheduler: CPU ConCurrency
Date: Thu, 15 May 2014 16:50:42 +0200 [thread overview]
Message-ID: <20140515145042.GO30445@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20140506184637.GA17884@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
On Wed, May 07, 2014 at 02:46:37AM +0800, Yuyang Du wrote:
> > The general code structure is an immediate no go. We're not going to
> > bolt on anything like this.
>
> Could you please detail a little bit about general code structure?
So I should have just deleted all patches, for none of them has a
changelog.
So all this cc crap only hooks into and modifies fair.c behaviour. There
is absolutely no reason it should live anywhere else except fair.c
Secondly, the very last thing we need is more CONFIG_ goo, and you
sprinkle #ifdef around like it was gold dust.
Thirdly, wth is wrong with the current per-task runtime accounting and
why can't you extend/adapt that instead of duplicating the lot.
Fourthly, I'm _never_ going to merge anything that hijacks the load
balancer and does some random other thing. There's going to be a single
load-balancer full stop.
Many people have expressed interest in a packing balancer (vs the
spreading we currently default to). Some have even done patches.
At the same time it seems very difficult to agree on _when_ packing
makes sense. That said, when we do packing we should do it driven by the
topology and policy, not by some compile time option.
Lastly, if you'd done your homework and actually read some of the
threads on the subject from say the past two years, you'd know pretty
much all that already.
I'm not here to endlessly repeat myself and waste time staring at
unchangelogged patches.
Anyway, there might or might not be useful ideas in there.. but its very
hard to tell one way or another.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-05-15 14:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 0:02 [RFC PATCH 00/12 v1] A new CPU load metric for power-efficient scheduler: CPU ConCurrency Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 01/12 v1] CONFIG for " Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 02/12 v1] Init " Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 03/12 v1] CPU ConCurrency calculation Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 04/12 v1] CPU ConCurrency collecting in: Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 05/12 v1] CONFIG for Workload Consolidation Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 06/12 v1] Attach CPU topology Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 07/12 v1] CPU ConCurrency API for Workload Consolidation Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 08/12 v1] Intercept wakeup/fork/exec balance Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 09/12 v1] Intercept idle balance Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 10/12 v1] Intercept periodic nohz " Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 11/12 v1] Intercept periodic load balance Yuyang Du
2014-05-05 0:02 ` [RFC PATCH 12/12 v1] Intercept RT provocatively Yuyang Du
2014-05-05 9:37 ` [RFC PATCH 00/12 v1] A new CPU load metric for power-efficient scheduler: CPU ConCurrency Peter Zijlstra
2014-05-06 18:46 ` Yuyang Du
2014-05-15 14:50 ` Peter Zijlstra [this message]
2014-05-18 19:16 ` Yuyang Du
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=20140515145042.GO30445@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ajaya.durg@intel.com \
--cc=alan.cox@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=harinarayanan.seshadri@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.gross@intel.com \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=nicole.chalhoub@intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rajeev.d.muralidhar@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vishwesh.m.rudramuni@intel.com \
--cc=yuyang.du@intel.com \
/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