All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuyang Du <yuyang.du@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
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: Mon, 19 May 2014 03:16:56 +0800	[thread overview]
Message-ID: <20140518191656.GB18818@intel.com> (raw)
In-Reply-To: <20140515145042.GO30445@twins.programming.kicks-ass.net>

> So I should have just deleted all patches, for none of them has a
> changelog.
> 

It is my bad to not make changelogs in patches. The v2 has them, but I should
have made them since always.

> 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.
> 

Aggreed. I will change these.

> Thirdly, wth is wrong with the current per-task runtime accounting and
> why can't you extend/adapt that instead of duplicating the lot.
> 

Sure. As you and Vincent said, CC will take a ride of current tracking codes
instead of duplicating.

> 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.
>

I will make "Workload Consolidation" driven by topology and policy,
essentially it is already so, but sure the codes are not completely clean in
that regard.

> 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.
> 

This will not happen again.

> Anyway, there might or might not be useful ideas in there.. but its very
> hard to tell one way or another.

I think the above is mostly about "amenability" to scheduler codes.
Apparently, I am not doing it right. Will send another version to
make it less hard. Thanks for your time.

Yuyang

      reply	other threads:[~2014-05-19  3:21 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
2014-05-18 19:16       ` Yuyang Du [this message]

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=20140518191656.GB18818@intel.com \
    --to=yuyang.du@intel.com \
    --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=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rajeev.d.muralidhar@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vishwesh.m.rudramuni@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 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.