From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Yuyang du <yuyang.du@intel.com>
Cc: peterz@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
morten.rasmussen@arm.com, arjan.van.de.ven@intel.com,
len.brown@intel.com, rafael.j.wysocki@intel.com,
alan.cox@intel.com
Subject: Re: [RFC II] Splitting scheduler into two halves
Date: Thu, 27 Mar 2014 05:57:13 +0100 [thread overview]
Message-ID: <1395896233.5512.45.camel@marge.simpson.net> (raw)
In-Reply-To: <20140326183721.GC24116@intel.com>
On Thu, 2014-03-27 at 02:37 +0800, Yuyang du wrote:
> Hi all,
>
> This is continued after the first RFC about splitting the scheduler. Still
> work-in-progress, and call for feedback.
>
> The question addressed here is how load balance should be changed. And I think
> the question then goes to how to *reuse* common code as much as possible and
> meanwhile be able to serve various objectives.
>
> So these are the basic semantics needed in current load balance:
I'll probably regret it, but I'm gonna speak my mind. I think this two
halves concept is fundamentally broken.
> 1. [ At balance point ] on this_cpu push task on that_cpu to [ third_cpu ]
Load balancing is a necessary part of the fastpath as well as slow path,
you can't just define balance point, and have that mean a point at which
we can separate core functionality from peripheral. For example, rt
class has push/pull at schedule time, fair class select_idle_sibling()
at wakeup, both in the fastpath, to minimize latency. It is all load
balancing, is push pull, fastpath does exactly the same things as slow
path, for the exact same reason, only resource investment varies.
I don't think you can separate the scheduler into two halves like this,
load balancing is an integral part and fundamental consequence of being
a multi-queue scheduler. Scheduling and balancing are not two halves
that make a whole, and can thus be separated, they are one.
-Mike
next prev parent reply other threads:[~2014-03-27 4:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 18:37 [RFC II] Splitting scheduler into two halves Yuyang du
2014-03-27 4:57 ` Mike Galbraith [this message]
2014-03-27 7:25 ` Ingo Molnar
2014-03-27 22:13 ` Yuyang Du
2014-03-28 6:50 ` Mike Galbraith
2014-03-27 23:00 ` Yuyang Du
2014-03-28 7:05 ` Mike Galbraith
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=1395896233.5512.45.camel@marge.simpson.net \
--to=umgwanakikbuti@gmail.com \
--cc=alan.cox@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@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 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.