From: Yuyang du <yuyang.du@intel.com>
To: peterz@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Cc: morten.rasmussen@arm.com, arjan.van.de.ven@intel.com,
len.brown@intel.com, rafael.j.wysocki@intel.com,
alan.cox@intel.com
Subject: [RFC II] Splitting scheduler into two halves
Date: Thu, 27 Mar 2014 02:37:21 +0800 [thread overview]
Message-ID: <20140326183721.GC24116@intel.com> (raw)
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:
1. [ At balance point ] on this_cpu push task on that_cpu to [ third_cpu ]
Examples are fork/exec/wakeup. Task is determined by the balance point in
question. And that_cpu is determined by task.
2. [ At balance point ] on this_cpu pull [ task/tasks ] on [ that_cpu ] to
this_cpu
Examples are other idle/periodic/nohz balance, and active_load_balance in
ASYM_PACKING (pull first and then a push).
3. [ At balance point ] on this_cpu kick [ that_cpu/those_cpus ] to do [ what
] balance
Examples are nohz idle balance and active balance.
To make the above more general, we need to abstract more:
1. [ At balance point ] on this_cpu push task on that_cpu to [ third_cpu ] in
[ cpu_mask ]
2. [ At balance point ] on this_cpu [ do | skip ] pull [task/tasks ] on [
that_cpu ] in [ cpu_mask ] to this_cpu
3. [ At balance point ] on this_cpu kick [ that_cpu/those_cpus ] in [ cpu_mask
] to do nohz idle balance
So essentially, we give them choice or restrict the scope for them.
Then instead of an all-in-one load_balance class, we define pull or push
classes:
struct push_class:
int (*which_third_cpu);
struct cpumask * (*which_cpu_mask);
struct pull_class:
int (*skip);
int (*which_that_cpu);
struct task_struct * (*which_task);
struct cpumask* (*which_cpu_mask);
Last but not least, currently we configure domain by flags/parameters, how
about attaching push/pull classes directly to them as struct members? So those
classes are responsible specially for its riding domain's "well-being".
Thanks,
Yuyang
next reply other threads:[~2014-03-27 2:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 18:37 Yuyang du [this message]
2014-03-27 4:57 ` [RFC II] Splitting scheduler into two halves Mike Galbraith
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=20140326183721.GC24116@intel.com \
--to=yuyang.du@intel.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 \
/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.