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:	Fri, 24 Apr 2015 16:07:52 -0400
From:	Gene Heskett <gheskett@...v.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Chris Metcalf <cmetcalf@...hip.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...nel.org>, Dave Jones <davej@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Oleg Nesterov <oleg@...hat.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...hat.com>, Rik van Riel <riel@...hat.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH 4/4] nohz: Set isolcpus when nohz_full is set

On Friday 24 April 2015 11:58:31 Frederic Weisbecker wrote:
> From: Chris Metcalf <cmetcalf@...hip.com>
>
> nohz_full is only useful with isolcpus also set, since otherwise the
> scheduler has to run periodically to try to determine whether to steal
> work from other cores.
>
> Accordingly, when booting with nohz_full=xxx on the command line, we
> should act as if isolcpus=xxx was also set, and set (or extend) the
> isolcpus set to include the nohz_full cpus.
>
> Acked-by: Mike Galbraith <umgwanakikbuti@...il.com> ["thumbs up!"]
> Acked-by: Rik van Riel <riel@...hat.com>
> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Signed-off-by: Chris Metcalf <cmetcalf@...hip.com>
> Cc: Peter Zijlstra (Intel) <peterz@...radead.org>
> Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>
> Cc: Mike Galbraith <umgwanakikbuti@...il.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Rik van Riel <riel@...hat.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>

As a user of LinuxCNC, we expect the core(s) so isolated by the isolcpus 
argument at bootup time to remain undisturbed in order to preserve the 
I/O updates heartbeat latency at the absolute minimum that board and cpu 
combo can accomplish.

If this patch changes that behaviour such that the isolated core is 
grabbed for another job while the RTAI bits and pieces are loaded and 
running machinery, causing the machinery to lose this steady, possibly 
as little as a 20 microsecond period repeating operation heartbeat, this 
will quite effectively destroy our ability to run this software on linux 
without farming that whole operation out to intelligent I/O cards.

Please keep this in mind.  I don't read the patch well enough to 
determine this myself.

> ---
>  kernel/sched/core.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 6f149f8..e95b4d8 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7042,6 +7042,9 @@ void __init sched_init_smp(void)
>  	alloc_cpumask_var(&non_isolated_cpus, GFP_KERNEL);
>  	alloc_cpumask_var(&fallback_doms, GFP_KERNEL);
>
> +	/* nohz_full won't take effect without isolating the cpus. */
> +	tick_nohz_full_add_cpus_to(cpu_isolated_map);
> +
>  	sched_init_numa();
>
>  	/*

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ