Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1252045 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick  at boot Frederic Weisbecker <fweisbec@gmail.com> - 2015-10-20 23:10 +0200
    Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick  at boot Chris Metcalf <cmetcalf@ezchip.com> - 2015-10-20 23:20 +0200
      Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum  tick at boot Steven Rostedt <rostedt@goodmis.org> - 2015-10-21 03:10 +0200
    RE: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick  at boot Gilad Ben Yossef <giladb@ezchip.com> - 2015-10-21 09:20 +0200
    Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick  at boot Christoph Lameter <cl@linux.com> - 2015-10-21 16:30 +0200
      Re: [PATCH v8 08/14] nohz_full: allow disabling the 1Hz minimum tick  at boot Frederic Weisbecker <fweisbec@gmail.com> - 2015-10-21 17:40 +0200

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

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 <cmetcalf@ezchip.com>

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1252048

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 <cmetcalf@ezchip.com>
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On Tue, 20 Oct 2015 17:18:13 -0400
Chris Metcalf <cmetcalf@ezchip.com> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252506

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

[toc] | [prev] | [next] | [standalone]

#1252855

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1252962

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web