linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 1 Nov 2014 20:18:11 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Christoph Lameter <cl@...ux.com>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	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>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Hugh Dickins <hughd@...gle.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [NOHZ] Remove scheduler_tick_max_deferment

On Fri, 31 Oct 2014, Christoph Lameter wrote:
> The reasoning behind this function is not clear to me and removal seems

The comment above the function is clear enough.

> to have a limited impact on the system overall. Even without the
> cap to 1 second the system will be limited by the boundaries on the period
> of interrupts by various devices (in my case I ended up with a 4 second
> interval on x86 because of the limitations of periodicy of the underlying
> interupt source).

And just because it happens to do so on your machine it's not
guaranteed. 
 
> Moreover this artificial limits the impact the benefit that commit
> commit 7cc36bbddde5cd0c98f0c06e3304ab833d662565 (on-demand vmstat workers)
> should be giving us.
> 
> Without this patch timer interrupts will still occur in 1 second intervals
> but no vmstat kworker will run. On a processor where all other

And what has this to do with vmstat kworker? Nothing.

> events have been redirected to other processors nothing will be
> going on just timer interrupts that do not do much.

What the timer interrupt does is very clearly explained in the comment
above the function you want to remove.
 
> With this patch the maximum deferrability of other items will become
> evident and work can then proceed on eliminating those

What about eliminating the requirement for this function first? It's
clear what it does and it's also clear that this can be done remotely
from a housekeeping cpu when the full nohz cpu is busy looping in user
space. The function is there because nobody has tackled that problem
yet.

> (like the 4 second limit that I encountered due to the timing
> limitations of the underlying hardware)

You don't want to tackle the 4 seconds limit of the underlying
hardware. What you really want is to eliminate the [hr]timer which is
preventing the hardware timer to be shutdown completely.

But we care about that _after_ we solved the scheduler tick
requirement because that is the most evident one.

Thanks,

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