Re: [NOHZ] Remove scheduler_tick_max_deferment

[Thomas Gleixner <tglx@linutronix.de>]

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