Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Frederic Weisbecker]

On Wed, Oct 21, 2015 at 09:28:04AM -0500, Christoph Lameter wrote:
> On Tue, 20 Oct 2015, Frederic Weisbecker wrote:
> 
> > 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.
> 
> Well this is a pretty bad argument. By that reasoning no one should be
> allowed to use root. After all stupid users will become root and kill
> processes that are hung. And the underlying issue that causes those hangs
> in processes will never be fixed because they will keep on killing
> processes.

I disagree. There is an signifiant frontier between:

_ hack it up and you're responsible of the consequences, yourself

  and
  
_ provide a buggy hack to the user and support this officially upstream


Especially as all I've seen in two years, wrt. solving the 1 Hz issue, is 
patches like this.
Almost nobody really tried to dig into the real issues that are well known and 
identified
after all now, and not that hard to fix: it's many standalone issues to make 
the scheduler
resilient with full-total-hard-dynticks.

The only effort toward that I've seen lately is:  
https://lkml.org/lkml/2015/10/14/192
and still I think the author came to that nohz issue by accident.

Many users are too easily happy with hacks like this and that one is a too much 
a good
opportunity for them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Christoph Lameter]

On Tue, 20 Oct 2015, Frederic Weisbecker wrote:

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

Well this is a pretty bad argument. By that reasoning no one should be
allowed to use root. After all stupid users will become root and kill
processes that are hung. And the underlying issue that causes those hangs
in processes will never be fixed because they will keep on killing
processes.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gilad Ben Yossef]

> From: Frederic Weisbecker [mailto:fweis...@gmail.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 
> 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Christoph Lameter]

On Tue, 20 Oct 2015, Frederic Weisbecker wrote:

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

Well this is a pretty bad argument. By that reasoning no one should be
allowed to use root. After all stupid users will become root and kill
processes that are hung. And the underlying issue that causes those hangs
in processes will never be fixed because they will keep on killing
processes.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Frederic Weisbecker]

On Wed, Oct 21, 2015 at 09:28:04AM -0500, Christoph Lameter wrote:
> On Tue, 20 Oct 2015, Frederic Weisbecker wrote:
> 
> > 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.
> 
> Well this is a pretty bad argument. By that reasoning no one should be
> allowed to use root. After all stupid users will become root and kill
> processes that are hung. And the underlying issue that causes those hangs
> in processes will never be fixed because they will keep on killing
> processes.

I disagree. There is an signifiant frontier between:

_ hack it up and you're responsible of the consequences, yourself

  and
  
_ provide a buggy hack to the user and support this officially upstream


Especially as all I've seen in two years, wrt. solving the 1 Hz issue, is 
patches like this.
Almost nobody really tried to dig into the real issues that are well known and 
identified
after all now, and not that hard to fix: it's many standalone issues to make 
the scheduler
resilient with full-total-hard-dynticks.

The only effort toward that I've seen lately is:  
https://lkml.org/lkml/2015/10/14/192
and still I think the author came to that nohz issue by accident.

Many users are too easily happy with hacks like this and that one is a too much 
a good
opportunity for them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gilad Ben Yossef]

> From: Frederic Weisbecker [mailto:fweis...@gmail.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 
> 
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Steven Rostedt]

On Tue, 20 Oct 2015 17:18:13 -0400
Chris Metcalf  wrote:

> So perhaps a boot flag is an acceptable compromise between
> "nothing" and a debugfs tweak?  It certainly does make it easier
> to hack on the task-isolation code, and likely other things where
> people are trying out fixes to subsystems where they are attempting
> to remove the reliance on the tick.
> 

Just change the name to:

this_will_crash_your_kernel_and_kill_your_kittens_debug_1hz_tick

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Chris Metcalf]

On 10/20/2015 05:03 PM, Frederic Weisbecker wrote:

On Tue, Oct 20, 2015 at 04:36:06PM -0400, Chris Metcalf wrote:

While the current fallback to 1-second tick is still required for
a number of kernel accounting tasks (e.g. vruntime, load balancing
data, and load accounting), it's useful to be able to disable it
for testing purposes.  Paul McKenney observed that if we provide
a mode where the 1Hz fallback timer is removed, this will provide
an environment where new code that relies on that tick will get
punished, and we won't forgive such assumptions silently.

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 

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.


Fair enough and certainly your prerogative, so don't hesitate to
say "no" to the following argument.  :-)

I would tend to differentiate a debugfs proposal from a boot flag
proposal: a boot flag is a more hardcore thing to change, and it's
not like application developers will come along and explain that
you have to boot with different flags to run their app - whereas
if they can just sneak in a modification to a debugfs setting that's
much easier for the app to tweak.

So perhaps a boot flag is an acceptable compromise between
"nothing" and a debugfs tweak?  It certainly does make it easier
to hack on the task-isolation code, and likely other things where
people are trying out fixes to subsystems where they are attempting
to remove the reliance on the tick.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Frederic Weisbecker]

On Tue, Oct 20, 2015 at 04:36:06PM -0400, Chris Metcalf wrote:
> While the current fallback to 1-second tick is still required for
> a number of kernel accounting tasks (e.g. vruntime, load balancing
> data, and load accounting), it's useful to be able to disable it
> for testing purposes.  Paul McKenney observed that if we provide
> a mode where the 1Hz fallback timer is removed, this will provide
> an environment where new code that relies on that tick will get
> punished, and we won't forgive such assumptions silently.
> 
> 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 

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Frederic Weisbecker]

On Tue, Oct 20, 2015 at 04:36:06PM -0400, Chris Metcalf wrote:
> While the current fallback to 1-second tick is still required for
> a number of kernel accounting tasks (e.g. vruntime, load balancing
> data, and load accounting), it's useful to be able to disable it
> for testing purposes.  Paul McKenney observed that if we provide
> a mode where the 1Hz fallback timer is removed, this will provide
> an environment where new code that relies on that tick will get
> punished, and we won't forgive such assumptions silently.
> 
> 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 

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Chris Metcalf]

On 10/20/2015 05:03 PM, Frederic Weisbecker wrote:

On Tue, Oct 20, 2015 at 04:36:06PM -0400, Chris Metcalf wrote:

While the current fallback to 1-second tick is still required for
a number of kernel accounting tasks (e.g. vruntime, load balancing
data, and load accounting), it's useful to be able to disable it
for testing purposes.  Paul McKenney observed that if we provide
a mode where the 1Hz fallback timer is removed, this will provide
an environment where new code that relies on that tick will get
punished, and we won't forgive such assumptions silently.

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 

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.


Fair enough and certainly your prerogative, so don't hesitate to
say "no" to the following argument.  :-)

I would tend to differentiate a debugfs proposal from a boot flag
proposal: a boot flag is a more hardcore thing to change, and it's
not like application developers will come along and explain that
you have to boot with different flags to run their app - whereas
if they can just sneak in a modification to a debugfs setting that's
much easier for the app to tweak.

So perhaps a boot flag is an acceptable compromise between
"nothing" and a debugfs tweak?  It certainly does make it easier
to hack on the task-isolation code, and likely other things where
people are trying out fixes to subsystems where they are attempting
to remove the reliance on the tick.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick at boot

[Steven Rostedt]

On Tue, 20 Oct 2015 17:18:13 -0400
Chris Metcalf  wrote:

> So perhaps a boot flag is an acceptable compromise between
> "nothing" and a debugfs tweak?  It certainly does make it easier
> to hack on the task-isolation code, and likely other things where
> people are trying out fixes to subsystems where they are attempting
> to remove the reliance on the tick.
> 

Just change the name to:

this_will_crash_your_kernel_and_kill_your_kittens_debug_1hz_tick

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/