diff options
author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2011-04-18 12:12:14 -0400 |
---|---|---|
committer | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2011-04-18 12:12:14 -0400 |
commit | fac56c2df51bc29b07b3c2dcfabf32a015a0522c (patch) | |
tree | 1ff5d84ecf4ea0bcbd42e2ef9624b5ade3810890 /Documentation/scheduler/sched-domains.txt | |
parent | 6caa15d0b84d2ea688fd31f4f172c8353463e109 (diff) | |
parent | a6360dd37e1a144ed11e6548371bade559a1e4df (diff) |
Merge commit 'v2.6.39-rc3' into for-2.6.39
Diffstat (limited to 'Documentation/scheduler/sched-domains.txt')
-rw-r--r-- | Documentation/scheduler/sched-domains.txt | 32 |
1 files changed, 23 insertions, 9 deletions
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index 373ceacc367e..b7ee379b651b 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt | |||
@@ -1,8 +1,7 @@ | |||
1 | Each CPU has a "base" scheduling domain (struct sched_domain). These are | 1 | Each CPU has a "base" scheduling domain (struct sched_domain). The domain |
2 | accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain | ||
3 | hierarchy is built from these base domains via the ->parent pointer. ->parent | 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 | 3 | MUST be NULL terminated, and domain structures should be per-CPU as they are |
5 | are locklessly updated. | 4 | locklessly updated. |
6 | 5 | ||
7 | Each scheduling domain spans a number of CPUs (stored in the ->span field). | 6 | Each scheduling domain spans a number of CPUs (stored in the ->span field). |
8 | A domain's span MUST be a superset of it child's span (this restriction could | 7 | A domain's span MUST be a superset of it child's span (this restriction could |
@@ -26,11 +25,26 @@ is treated as one entity. The load of a group is defined as the sum of the | |||
26 | load of each of its member CPUs, and only when the load of a group becomes | 25 | load of each of its member CPUs, and only when the load of a group becomes |
27 | out of balance are tasks moved between groups. | 26 | out of balance are tasks moved between groups. |
28 | 27 | ||
29 | In kernel/sched.c, rebalance_tick is run periodically on each CPU. This | 28 | In kernel/sched.c, trigger_load_balance() is run periodically on each CPU |
30 | function takes its CPU's base sched domain and checks to see if has reached | 29 | through scheduler_tick(). It raises a softirq after the next regularly scheduled |
31 | its rebalance interval. If so, then it will run load_balance on that domain. | 30 | rebalancing event for the current runqueue has arrived. The actual load |
32 | rebalance_tick then checks the parent sched_domain (if it exists), and the | 31 | balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run |
33 | parent of the parent and so forth. | 32 | in softirq context (SCHED_SOFTIRQ). |
33 | |||
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 | ||
40 | forth. | ||
41 | |||
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. | ||
34 | 48 | ||
35 | *** Implementing sched domains *** | 49 | *** Implementing sched domains *** |
36 | The "base" domain will "span" the first level of the hierarchy. In the case | 50 | The "base" domain will "span" the first level of the hierarchy. In the case |