linux-kernel - RE: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

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]

Message-ID: <AM2PR02MB04179DA4953034E1320DBB6FBD380@AM2PR02MB0417.eurprd02.prod.outlook.com>
Date:	Wed, 21 Oct 2015 06:56:38 +0000
From:	Gilad Ben Yossef <giladb@...hip.com>
To:	Frederic Weisbecker <fweisbec@...il.com>,
	Chris Metcalf <cmetcalf@...hip.com>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Christoph Lameter <cl@...ux.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Catalin Marinas <catalin.marinas@....com>,
	"Will Deacon" <will.deacon@....com>,
	Andy Lutomirski <luto@...capital.net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick
 at boot


> From: Frederic Weisbecker [mailto:fweisbec@...il.com]
> > This option also allows easy testing of nohz_full and task-isolation
> > modes to determine what functionality needs to be implemented,
> > and what possibly-spurious timer interrupts are scheduled when
> > the basic 1Hz tick has been turned off.
> >
> > Signed-off-by: Chris Metcalf <cmetcalf@...hip.com>
> 
> There have been proposals to disable/tune the 1 Hz tick via debugfs which
> I Nacked because once you give such an opportunity to the users, they
> will use that hack and never fix the real underlying issue.
> 
> For the same reasons, I'm sorry but I have to Nack this proposal as well.
> 
> If this is for development or testing purpose,
> scheduler_max_tick_deferment() is
> easily commented out.

The problem with the latter is that it is much easier get back to one of the poor^H^H^H^H brave souls that are  
willing to risk their kittens testing this stuff for us saying: "can you please boot without this boot option and let 
me know if that behavior you were complaining about still happens?" rather than "can you please go to this 
and that line in the source file and un-comment it and re-compile and see if it still happens?"

I hope this makes more sense.

Thinking about it, it's probably a good idea to taint the kernel when this option is set as well.

Thanks,
Gilad
--
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/