linux-kernel - Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max

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:	Tue, 11 Nov 2014 18:15:28 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Tejun Heo <tj@...nel.org>,
	John Stultz <john.stultz@...aro.org>,
	Mike Frysinger <vapier@...too.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Max Krasnyansky <maxk@....qualcomm.com>,
	Hugh Dickins <hughd@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Kevin Hilman <khilman@...aro.org>
Subject: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove
 scheduler_tick_max_deferment)

On Mon, Nov 10, 2014 at 12:26:51PM -0600, Christoph Lameter wrote:
> >
> > Would it make sense for unlimited max deferment to be available as
> > a boot parameter?  That would allow people who want tick-free execution
> > more than accurate stats to get that easily, while keeping stats accurate
> > for everyone else.
> 
> Subject: Make the maximum tick deferral for CONFIG_NO_HZ configurable
> 
> Add a way to configure this interval at boot and via
> /proc/sys/vm/max_defer_tick
> 
> Signed-off-by: Christoph Lameter <cl@...ux.com>

Sorry but that's not solving the problem. All it does is to allow the user
to tune bugs.

Kevin Hilman proposed something similar using debugfs and I declined it as
well. Integrating a hack like this is a good way to make sure that nobody
will ever fix the real underlying issue.

BTW, that's a good opportunity for me to generalize this case to the full
dynticks development general issue. I got a lot of help from people to improve
the kernel's isolation and full dynticks: Paul has spent a lot of time to improve
RCU, you improved vmstat, full dynticks got ported to other archs, people
like Viresh fixed some timers internals, Gilad fixed IPIs, Peterz reviewed a
lot, etc...

But now we reached a step where there are mostly core issues remaining that
require some infrastrure change investments, some extensions or a bit of rethinking.
We know we reach that step when people who want the features are stuck sending
workarounds.
Nothing like big rewrites is needed really, actually just a bunch of pretty
self contained issues. And by self-contained I mean that each of these individual
problems can be worked out seperately as they are unrelated enough altogether. Here is
a summarized list:

* Unbound workqueues affinity (to housekeeper)
* Unbound timers affinity (to housekeeper)
* 1 Hz residual scheduler tick offlining to housekeeper
* Fix some scheduler accounting that don't even work with 1 Hz: cpu load
  accounting, rt_scale, load balancing, etc...
* Lighten the syscall path and get rid of cputime accounting + RCU hooks
  for people who want isolation + fast syscalls and faults.
* Work on non-affinable workqueues
* Work on non-affinable timers
* ...

If I'm going to work alone on all that, this is going to take several years,
honestly.

But we know what to do and how. So all we need is (at least one) more full time
core developer to get these things done in a reasonable amount of time.

Thanks.
--
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/