linux-kernel - Re: [PATCH RFC] select_idle

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, 28 Apr 2016 14:00:12 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Mike Galbraith <mgalbraith@...e.de>
Cc:	Chris Mason <clm@...com>, Ingo Molnar <mingo@...nel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] select_idle_sibling experiments

On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> sched: ratelimit nohz
> 
> Entering nohz code on every micro-idle is too expensive to bear.
> 
> Signed-off-by: Mike Galbraith <efault@....de>

> +int sched_needs_cpu(int cpu)
> +{
> +	if (tick_nohz_full_cpu(cpu))
> +		return 0;
> +
> +	return  cpu_rq(cpu)->avg_idle < sysctl_sched_migration_cost;

So the only problem I have with this patch is the choice of limit. This
isn't at all tied to the migration cost.

And some people are already twiddling with the migration_cost knob to
affect the idle_balance() behaviour -- making it much more agressive by
dialing it down. When you do that you also loose the effectiveness of
this proposed usage, even though those same people would probably want
this.

Failing a spot of inspiration for a runtime limit on this; we might have
to introduce yet another knob :/