linux-kernel - Re: [patch 2/2] sched: dynticks idle load balancing

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Feb 2007 04:26:54 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: [patch 2/2] sched: dynticks idle load balancing - v2

On Fri, Feb 16, 2007 at 06:08:42PM -0800, Suresh B wrote:
> Changes since v1:
> 
>   - Move the idle load balancer selection from schedule()
>     to the first busy scheduler_tick() after restarting the tick.
>     This will avoid the unnecessay ownership changes when 
>     softirq's(which are run in softirqd context in certain -rt
>     configurations) like timer, sched are invoked for every idle tick
>     that happens.
> 
>   - Misc cleanups.
> 
> ---
> Fix the process idle load balancing in the presence of dynticks.
> cpus for which ticks are stopped will sleep till the next event wakes it up.
> Potentially these sleeps can be for large durations and during which today,
> there is no periodic idle load balancing being done.
> 
> This patch nominates an owner among the idle cpus, which does the idle load
> balancing on behalf of the other idle cpus. And once all the cpus are
> completely idle, then we can stop this idle load balancing too. Checks added
> in fast path are minimized.  Whenever there are busy cpus in the system, there
> will be an owner(idle cpu) doing the system wide idle load balancing.

This is really ugly, sorry :(

My suggestion for handling this was to increase the maximum balance
interval for an idle CPU, and just implement a global shutdown when
the entire system goes idle.

The former should take care of the power savings issues for bare metal
hardware, and the latter should solve performance problems for many idle
SMP guests. It should take very little code to implement.

If that approach doesn't cut it, then at least we can have some numbers
to see how much better yours is so we can justify including it.

If you are against my approach, then I can have a try at coding it up
if you like?
-
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/