At the moment, balance_tasks() provides low level functionality for both
move_tasks() and move_one_task() (indirectly) via the load_balance()
function (in the sched_class interface) which also provides dual
functionality. This dual functionality complicates the interfaces and
internal mechanisms and makes the run time overhead of operations that
are called with two run queue locks held.
This patch addresses this issue and reduces the overhead of these
operations.
This patch is not urgent and can be held back until the next merge
window without compromising the safety of the kernel.
Signed-off-by: Peter Williams <[email protected]>
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
* Peter Williams <[email protected]> wrote:
> At the moment, balance_tasks() provides low level functionality for
> both
> move_tasks() and move_one_task() (indirectly) via the load_balance()
> function (in the sched_class interface) which also provides dual
> functionality. This dual functionality complicates the interfaces and
> internal mechanisms and makes the run time overhead of operations that
> are called with two run queue locks held.
>
> This patch addresses this issue and reduces the overhead of these
> operations.
hm, i like it, and added it to my queue (probably .24 material though),
but note that it increases .text and .data overhead:
text data bss dec hex filename
41028 37794 2168 80990 13c5e sched.o.before
41349 37826 2168 81343 13dbf sched.o.after
is that expected?
Ingo
Ingo Molnar wrote:
> * Peter Williams <[email protected]> wrote:
>
>> At the moment, balance_tasks() provides low level functionality for
>> both
>> move_tasks() and move_one_task() (indirectly) via the load_balance()
>> function (in the sched_class interface) which also provides dual
>> functionality. This dual functionality complicates the interfaces and
>> internal mechanisms and makes the run time overhead of operations that
>> are called with two run queue locks held.
>>
>> This patch addresses this issue and reduces the overhead of these
>> operations.
>
> hm, i like it, and added it to my queue (probably .24 material though),
> but note that it increases .text and .data overhead:
>
> text data bss dec hex filename
> 41028 37794 2168 80990 13c5e sched.o.before
> 41349 37826 2168 81343 13dbf sched.o.after
>
> is that expected?
Yes, sort off. It's a trade off of space for time and I expected an
increase (although I didn't think that it would be quite that much).
But it's still less than 1% and since the time saved is time when two
run queue locks are held I figure that it's a trade worth making. Also
this separation lays the ground for a clean up of the active load
balancing code which should gain some space including making it possible
to exclude active load balancing on systems that don't need it (i.e.
those that don't have multiple multi core/hyperthreading packages).
I've got a patch available that reduces the .text and .data for non SMP
systems by excluding the load balancing stuff (that has crept into those
systems) so that should help on embedded systems where memory is tight.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce