linux-kernel - Re: [PATCH 07/32] cpuset: Set up interface for nohz flag

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: <alpine.DEB.2.00.1203221118550.25011@router.home>
Date:	Thu, 22 Mar 2012 11:26:14 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Mike Galbraith <efault@....de>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Ingo Molnar <mingo@...nel.org>,
	Max Krasnyansky <maxk@...lcomm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Zen Lin <zen@...nhuawei.org>
Subject: Re: [PATCH 07/32] cpuset: Set up interface for nohz flag

On Thu, 22 Mar 2012, Mike Galbraith wrote:

> > > We use here a per cpu refcounter. As long as a CPU
> > > is contained into at least one cpuset that has the
> > > nohz flag set, it is part of the set of CPUs that
> > > run into adaptive nohz mode.
> >
> > What are the drawbacks for nohz?
>
> For nohz in general, latency.  To make it at all usable for rt loads, I

Well nohz while a process is running on a dedicated cpu means the cpu is
running full power and no disruptions occur. This is a tremendous benefit.

> had to make isolated cores immune from playing load balancer.  Even so,
> to achieve target latency, I had to hack up cpusets to let the user
> dynamically switch nohz off for specified sets (and the tick has to be
> skewed in both cases or you can just forget it).  With nohz, I can't
> quite achieve 30us jitter target, turn it off, I get single digit.  Out

Less than 10us jitter can alrady be accomplished by building a kernel with
certain options off (like for example preemption...) and ensuring that
stuff stays off certain processors. Lets not confuse realtime with low
latency. Real time in the sense of deterministic execution is bad for
latency because overhead is added to ensure the determinism which
increases latency.

I have a patch here that adds a system call to simply switch off the timer
interrupt cold turkey and with that I can get down to 1-2 usecs jitter.

> of the current box, triple digit for simple synchronized frame timers +
> compute worker-bees load on 64 cores.  Patch 4 probably helps that, but
> don't _think_ it'll fix it.  If you (currently) ever become balancer,
> you're latency target is smoking wreckage.

Yes so we need something to tell the system which cpu is the sacrificial
lamb that will not run low latency applications.
--
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/