linux-kernel - Re: [PATCH 4/4] nohz: New option to force all CPUs in full dynticks range

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 Mar 2013 10:10:37 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.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>,
	Kevin Hilman <khilman@...aro.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>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 4/4] nohz: New option to force all CPUs in full dynticks
 range


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

> 2013/3/28 Ingo Molnar <mingo@...nel.org>:
> >
> > * Frederic Weisbecker <fweisbec@...il.com> wrote:
> >
> >> +config NO_HZ_EXTENDED_ALL
> >> +       bool "Full dynticks system on all CPUs"
> >> +       depends on NO_HZ_EXTENDED
> >> +       help
> >> +      Force all CPUs to be full dynticks. The range specified in the
> >> +      nohz_extended boot option will then be ignored.
> >> +
> >> +      Note the boot CPU will still be kept outside the range to handle
> >> +      the timekeeping duty.
> >
> > In most cases this will be the first time users doing 'make oldconfig'
> > will hear about this feature, so I'd not mention noh_extended in such a
> > primary way at all.
> >
> > Instead I'd suggest to explain, in a few simple sentences, what 'full
> > dynticks' _is_. Then maybe mention this near the end of the next:
> >
> >    ( Alternatively this feature can also be enabled via the
> >      nohz_extended=<cpulist> boot option. If this kernel config option is
> >      enabled then the nohz_extended boot parameter is ignored. )
> 
> Ok. Hmm, concerning what full dynticks is, those who run make oldconfig 
> should have passed through CONFIG_NO_HZ_EXTENDED help first so they 
> should know what this is all about, right? I can improve its help text 
> if you think something need more details. Or you think I should add some 
> more reminder in the new config? Also nohz_extended is not mentioned 
> there so I indeed need to fix that. And then do a reminder in the new 
> config. I'll reuse a bit your above sentence.

Kconfig option + boot parameter, or kconfig option + kconfig option, just 
to get a feature to activate, is usability madness.

I think we need _one_ config knob to configure, which, if selected, 
activates all of this feature. Preferably this would be similar to the 
preempt options, like CONFIG_PREEMPT is the most advanced preemption 
model:

          ( ) No Forced Preemption (Server)
          (X) Voluntary Kernel Preemption (Desktop)
          ( ) Preemptible Kernel (Low-Latency Desktop)

NO_HZ_EXTENDED or NO_HZ_FULL could be a third variant to:

          ( ) Periodic Timer Ticks
          (X) Tickless Idle (Dynamic Ticks)
          ( ) Full Tickless (Extended Dynamic Ticks)

or so - instead of this somewhat confusing hierarchy of config and boot 
options. Good help text would explain the differences between then.

Internally, the 'Tickless Idle' option would cause NO_HZ to be set, while 
'Full Tickless' would also set NO_HZ, but would also set NO_HZ_EXTENDED.

Furthermore, right now it's hard to enable NO_HZ_EXTENDED, because it 
depends on so many other options. The option is just hidden unless the 
user knows about it and enables 5 other kernel options. Instead the tick 
mode selected should enable (select) any required features - it should 
drive things, not the other way around.

(After all that is done, the boot option is something that augments this 
existing, kconfig driven mechanism.)

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/