1
Each CPU has a "base" scheduling domain (struct sched_domain). These are
2
accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain
1
Each CPU has a "base" scheduling domain (struct sched_domain). The domain
3
2
hierarchy is built from these base domains via the ->parent pointer. ->parent
4
MUST be NULL terminated, and domain structures should be per-CPU as they
5
are locklessly updated.
3
MUST be NULL terminated, and domain structures should be per-CPU as they are
7
6
Each scheduling domain spans a number of CPUs (stored in the ->span field).
8
7
A domain's span MUST be a superset of it child's span (this restriction could
26
25
load of each of its member CPUs, and only when the load of a group becomes
27
26
out of balance are tasks moved between groups.
29
In kernel/sched.c, rebalance_tick is run periodically on each CPU. This
30
function takes its CPU's base sched domain and checks to see if has reached
31
its rebalance interval. If so, then it will run load_balance on that domain.
32
rebalance_tick then checks the parent sched_domain (if it exists), and the
33
parent of the parent and so forth.
28
In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
29
through scheduler_tick(). It raises a softirq after the next regularly scheduled
30
rebalancing event for the current runqueue has arrived. The actual load
31
balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
32
in softirq context (SCHED_SOFTIRQ).
34
The latter function takes two arguments: the current CPU and whether it was idle
35
at the time the scheduler_tick() happened and iterates over all sched domains
36
our CPU is on, starting from its base domain and going up the ->parent chain.
37
While doing that, it checks to see if the current domain has exhausted its
38
rebalance interval. If so, it runs load_balance() on that domain. It then checks
39
the parent sched_domain (if it exists), and the parent of the parent and so
42
Initially, load_balance() finds the busiest group in the current sched domain.
43
If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in
44
that group. If it manages to find such a runqueue, it locks both our initial
45
CPU's runqueue and the newly found busiest one and starts moving tasks from it
46
to our runqueue. The exact number of tasks amounts to an imbalance previously
47
computed while iterating over this sched domain's groups.
35
49
*** Implementing sched domains ***
36
50
The "base" domain will "span" the first level of the hierarchy. In the case