Date:	Sat, 1 Nov 2014 16:52:13 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Thomas Gleixner <tglx@...utronix.de>
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 Sat, 1 Nov 2014, Thomas Gleixner wrote:

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

I looked around into the functions called by the timer interrupt for
accounting etc. They have measures to compensate if the HZ is not
occurring for some time.

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

When would it not occur? Where do we lack a measure to cope with missing
timer interrupts now?

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

This means that the timer interrupt occurs needlessly.

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

Could you be specific?

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

Where does that requirement exist?


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

Yes after the 1 second issue here has been avoided we can move on to the 4
second one and so on.

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

Why does the scheduler require that tick? It seems that the processor is
always busy running exactly 1 process when the tick is not
occurring. Anything else will switch on the tick again. So the information
that the scheduler has never becomes outdated.




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