sched-domains.rst 4.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485
  1. =================
  2. Scheduler Domains
  3. =================
  4. Each CPU has a "base" scheduling domain (struct sched_domain). The domain
  5. hierarchy is built from these base domains via the ->parent pointer. ->parent
  6. MUST be NULL terminated, and domain structures should be per-CPU as they are
  7. locklessly updated.
  8. Each scheduling domain spans a number of CPUs (stored in the ->span field).
  9. A domain's span MUST be a superset of it child's span (this restriction could
  10. be relaxed if the need arises), and a base domain for CPU i MUST span at least
  11. i. The top domain for each CPU will generally span all CPUs in the system
  12. although strictly it doesn't have to, but this could lead to a case where some
  13. CPUs will never be given tasks to run unless the CPUs allowed mask is
  14. explicitly set. A sched domain's span means "balance process load among these
  15. CPUs".
  16. Each scheduling domain must have one or more CPU groups (struct sched_group)
  17. which are organised as a circular one way linked list from the ->groups
  18. pointer. The union of cpumasks of these groups MUST be the same as the
  19. domain's span. The group pointed to by the ->groups pointer MUST contain the CPU
  20. to which the domain belongs. Groups may be shared among CPUs as they contain
  21. read only data after they have been set up. The intersection of cpumasks from
  22. any two of these groups may be non empty. If this is the case the SD_OVERLAP
  23. flag is set on the corresponding scheduling domain and its groups may not be
  24. shared between CPUs.
  25. Balancing within a sched domain occurs between groups. That is, each group
  26. is treated as one entity. The load of a group is defined as the sum of the
  27. load of each of its member CPUs, and only when the load of a group becomes
  28. out of balance are tasks moved between groups.
  29. In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
  30. through scheduler_tick(). It raises a softirq after the next regularly scheduled
  31. rebalancing event for the current runqueue has arrived. The actual load
  32. balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
  33. 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
  40. forth.
  41. Initially, load_balance() finds the busiest group in the current sched domain.
  42. If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in
  43. that group. If it manages to find such a runqueue, it locks both our initial
  44. CPU's runqueue and the newly found busiest one and starts moving tasks from it
  45. to our runqueue. The exact number of tasks amounts to an imbalance previously
  46. computed while iterating over this sched domain's groups.
  47. Implementing sched domains
  48. ==========================
  49. The "base" domain will "span" the first level of the hierarchy. In the case
  50. of SMT, you'll span all siblings of the physical CPU, with each group being
  51. a single virtual CPU.
  52. In SMP, the parent of the base domain will span all physical CPUs in the
  53. node. Each group being a single physical CPU. Then with NUMA, the parent
  54. of the SMP domain will span the entire machine, with each group having the
  55. cpumask of a node. Or, you could do multi-level NUMA or Opteron, for example,
  56. might have just one domain covering its one NUMA level.
  57. The implementor should read comments in include/linux/sched.h:
  58. struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
  59. the specifics and what to tune.
  60. Architectures may retain the regular override the default SD_*_INIT flags
  61. while using the generic domain builder in kernel/sched/core.c if they wish to
  62. retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
  63. can be done by #define'ing ARCH_HASH_SCHED_TUNE.
  64. Alternatively, the architecture may completely override the generic domain
  65. builder by #define'ing ARCH_HASH_SCHED_DOMAIN, and exporting your
  66. arch_init_sched_domains function. This function will attach domains to all
  67. CPUs using cpu_attach_domain.
  68. The sched-domains debugging infrastructure can be enabled by enabling
  69. CONFIG_SCHED_DEBUG. This enables an error checking parse of the sched domains
  70. which should catch most possible errors (described above). It also prints out
  71. the domain structure in a visual format.