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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/