linux-kernel - Re: [ANNOUNCE] 3.8-rc6-nohz4

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: <CAFTL4hzJ9FLNTqiBdB0SCWvxgN=p=M54e1PNWe6cp+C9A=DXxA@mail.gmail.com>
Date:	Thu, 7 Feb 2013 17:41:21 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Christoph Lameter <cl@...ux.com>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung.kim@....com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [ANNOUNCE] 3.8-rc6-nohz4

2013/2/7 Steven Rostedt <rostedt@...dmis.org>:
> I'll reply to this as I come up with comments.
>
> First thing is, don't call it NO_HZ_FULL. A better name would be
> NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we totally remove
> jiffies :-)

I'm not sure we'll ever be able to completely remove the tick, even if
jiffies is removed.
Ok in any case, NO_HZ_ADAPTIVE is probably a more accurate name.

>
> And the kconfig help should probably call it "Adaptive tickless" or
> "Tickless for single tasks". The full tickless system really sounds like
> we totally removed jiffies. It should explain it better. Something like:
>
>   "Adaptive tickless system"

Right the problem with "tickless" is its meaning of absolute removal.
"Full dynticks" is what I think reflect best what's happening.

> With this option, you may designate CPUs that will turn off the periodic
> interrupt "tick" when only a single task is scheduled on the CPU. This
> is similar to NO_HZ where the tick is suspended when the CPU goes into
> idle. With this option, it takes it one step further. When only a single
> task is scheduled on the CPU, there scheduler does not need to keep
> track of time slices, as the running task does not need to be preempted
> for other tasks. Stopping the tick allows the task to avoid being
> interrupted by service routines by the kernel.
>
> CPUs must be designated at time of boot via the kernel command line
> parameter (cpu_nohz) and must be a subset of the rcu_nocb parameter,
> which prevents RCU service routines from being called on the CPUs as
> well.
>
> ---
>
> Something like that.

I'm not convinced that "single task" must be a fundamental component
of this. It's an implementation detail. We should be able to keep the
tick off in the future when more than one task are on the runqueue and
hrtick is on. May be this will never show up as a performance gain but
we don't know yet.

Ok let's talk about that single task constraint in the Kconfig help so
that the user knows the practical constraint as of today. But I
suggest we keep that as an internal detail that we can deal with in
the future.

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