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, 07 Feb 2013 14:19:58 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	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>,
	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

On Thu, 2013-02-07 at 20:07 +0100, Ingo Molnar wrote:

> Could we just simplify things and make this an unconditional 
> option of NO_HZ? Any reason why we'd want to make this 
> configurable, other than debugging?

I think the worry is the overhead that is required to keep it active. It
requires the context_tracking being enabled. Although, we may be able to
have both working. 

Frederic, can we switch between context_tracking timing and tick base at
run time?

If we can have it enabled without overhead then I see no problem with
it. We still need the boot time kernel parameter to implement it. Hmm,
even if we can't dynamically switch between context_tracking and tick
base, we could make that decision at boot up based off of the kernel
parameters.


> 
> I'm worried about the proliferation of not easily separable 
> config options. We already have way too many timer and scheduler 
> options to begin with.

I agree.

> 
> > At least for now we seem to agree on CONFIG_NO_HZ_IDLE and 
> > keep CONFIG_NO_HZ for compatibility. Are you ok with that? If 
> > so I'll send a patch.
> 
> What would be the name of the new config option?
> 
> Can we just keep CONFIG_NO_HZ and extend it with your bits, and 
> make sure they work well?

As long as we do not introduce performance regressions. If we can keep
it active without causing the system to slow down when not in use, then
I think it should be always enabled if CONFIG_NO_HZ is selected.

-- Steve


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