linux-kernel - Re: [PATCH] sched: Reduce overhead in balance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 25 Aug 2007 11:50:38 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Nick Piggin <npiggin@...e.de>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sched: Reduce overhead in balance_tasks()

Ingo Molnar wrote:
> * Peter Williams <pwil3058@...pond.net.au> 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                                   pwil3058@...pond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/