linux-kernel - Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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]

Message-ID: <0000014109b3f0bf-c60a4ca2-91f2-4058-acec-bedfa4718a8d-000000@email.amazonses.com>
Date:	Tue, 10 Sep 2013 21:08:09 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Frysinger <vapier@...too.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
 cpus.

On Tue, 10 Sep 2013, Gilad Ben-Yossef wrote:

> as little interference as possible, one needs to pass
> rcu_nocbs, isolcpus, nohz_full parameters and now kthread parameter,
> all pretty much with the same values
>
> I know some people won't like this, but can we perhaps fold all these
> into a single parameter, perhaps even the existing isolcpus?

I have made similar suggestions before. Maybe even autoconfigure the whole
thing? Dedicate the first processor on each numa node to high latency OS
tasksk and keep the rest as noisefree as possible?


--
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/