Messages in this thread | | | Date | Thu, 14 Feb 2008 12:15:44 -0600 | From | Paul Jackson <> | Subject | Re: [RFC][PATCH 0/2] reworking load_balance_monitor |
| |
Peter wrote of: > the lack of rd->load_balance.
Could you explain to me a bit what that means?
Does this mean that the existing code would, by default (default being a single sched domain, covering the entire system's CPUs) load balance across the entire system, but with your rework, not so load balance there? That seems unlikely.
In any event, from my rather cpuset-centric perspective, there are only two common cases to consider.
1. In the default case, build_sched_domains() gets called once, at init, with a cpu_map of all non-isolated CPUs, and we should forever after load balance across all those non-isolated CPUs.
2. In some carefully managed systems using the per-cpuset 'sched_load_balance' flags, we tear down that first default sched domain, by calling detach_destroy_domains() on it, and we then setup some number of sched_domains (typically in the range of two to ten, though I suppose we should design to scale to hundreds of sched domains, on systems with thousands of CPUs) by additional calls to build_sched_domains(), such that their CPUs don't overlap (pairwise disjoint) and such that the union of all their CPUs may, or may not, include all non-isolated CPUs (some CPUs might be left 'out in the cold', intentionally, as essentially additional isolated CPUs.) We would then expect load balancing within each of these pair-wise disjoint sched domains, but not between one of them and another.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |