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


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> 2013/2/7 Ingo Molnar <mingo@...nel.org>:
> >
> > * Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> >> 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 don't think we want yet another config option named in a
> > weird way.
> >
> > What we want instead is to just split NO_HZ up into its
> > conceptual parts:
> >
> >    CONFIG_NO_HZ_IDLE
> 
> Renaming CONFIG_NO_HZ to CONFIG_NO_HZ_IDLE is something I 
> considered. I was just worried about this option being present 
> in many defconfig.

I don't think renaming it is an option - it's present not just 
in defconfigs, but in various distro configs, etc.

But we can add new config variables and use the existing 
CONFIG_NO_HZ value to set their default values.

> Perhaps we can do that renaming and keep CONFIG_NO_HZ around a 
> little while for backward compatibility (pretty much like what 
> we've done for CONFIG_PERF_COUNTERS -> CONFIG_PERF_EVENTS).

Yes.

> >    CONFIG_NO_HZ_USER_SPACE
> >    CONFIG_NO_HZ_KERNEL_SPACE
> >
> > Where the current status quo is NO_HZ_IDLE=y, and Frederic is
> > about to introduce NO_HZ_USER_SPACE=y. When jiffies get removed
> > we get NO_HZ_KERNEL_SPACE=y.
> 
> Note on my tree I stop the tick on both rings. I believe that 
> restarting the tick on kernel entry isn't something we should 
> seriously consider. It would be a costly operation that may 
> make things worse. And in fact there is no big difference. 
> Just kernelspace has more opportunities to be disturbed (RCU 
> IPIs, async timer/work scheduled by the kernel, etc...) and 
> get its tick restarted sometimes.

Ok.

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'm worried about the proliferation of not easily separable 
config options. We already have way too many timer and scheduler 
options to begin with.

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

Thanks,

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