Disabling NO_HZ has a serious negative effect on performance -- an extra
70us per I/O. Prevent users from deselecting it.
Signed-off-by: Matthew Wilcox <[email protected]>
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index f06a8a3..55b9a04 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -5,13 +5,9 @@ config TICK_ONESHOT
bool
config NO_HZ
- bool "Tickless System (Dynamic Ticks)"
+ def_bool y
depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
select TICK_ONESHOT
- help
- This option enables a tickless system: timer interrupts will
- only trigger on an as-needed basis both when the system is
- busy and when the system is idle.
config HIGH_RES_TIMERS
bool "High Resolution Timer Support"
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Wednesday, December 22, 2010, Matthew Wilcox wrote:
>
> Disabling NO_HZ has a serious negative effect on performance -- an extra
> 70us per I/O. Prevent users from deselecting it.
>
> Signed-off-by: Matthew Wilcox <[email protected]>
OTOH, it causes some systems to not work at all still. Sadly.
Thanks,
Rafael
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index f06a8a3..55b9a04 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -5,13 +5,9 @@ config TICK_ONESHOT
> bool
>
> config NO_HZ
> - bool "Tickless System (Dynamic Ticks)"
> + def_bool y
> depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
> select TICK_ONESHOT
> - help
> - This option enables a tickless system: timer interrupts will
> - only trigger on an as-needed basis both when the system is
> - busy and when the system is idle.
>
> config HIGH_RES_TIMERS
> bool "High Resolution Timer Support"
>
>
On Wed, Dec 22, 2010 at 12:46:23AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, December 22, 2010, Matthew Wilcox wrote:
> >
> > Disabling NO_HZ has a serious negative effect on performance -- an extra
> > 70us per I/O. Prevent users from deselecting it.
> >
> > Signed-off-by: Matthew Wilcox <[email protected]>
>
> OTOH, it causes some systems to not work at all still. Sadly.
It doesn't stop people from specifying nohz=off on the kernel command line.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Wednesday, December 22, 2010, Matthew Wilcox wrote:
> On Wed, Dec 22, 2010 at 12:46:23AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, December 22, 2010, Matthew Wilcox wrote:
> > >
> > > Disabling NO_HZ has a serious negative effect on performance -- an extra
> > > 70us per I/O. Prevent users from deselecting it.
> > >
> > > Signed-off-by: Matthew Wilcox <[email protected]>
> >
> > OTOH, it causes some systems to not work at all still. Sadly.
>
> It doesn't stop people from specifying nohz=off on the kernel command line.
Which still doesn't work for some people AFAICT.
Thanks,
Rafael
On 12/21/10 15:39, Matthew Wilcox wrote:
>
> Disabling NO_HZ has a serious negative effect on performance -- an extra
> 70us per I/O. Prevent users from deselecting it.
>
> Signed-off-by: Matthew Wilcox <[email protected]>
>
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index f06a8a3..55b9a04 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -5,13 +5,9 @@ config TICK_ONESHOT
> bool
>
> config NO_HZ
> - bool "Tickless System (Dynamic Ticks)"
> + def_bool y
> depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
> select TICK_ONESHOT
> - help
> - This option enables a tickless system: timer interrupts will
> - only trigger on an as-needed basis both when the system is
> - busy and when the system is idle.
>
> config HIGH_RES_TIMERS
> bool "High Resolution Timer Support"
Why remove the ability to make the configuration choice? Why not
just add the info about performance impact to the help text and
let me shoot myself in the foot (that is the unix way (tm)) if
I desire to?
(Yes I say your later reply about the kernel command line method
of shooting myself in the foot.)
-Frank
On Wed, Dec 22, 2010 at 01:00:37PM -0800, Frank Rowand wrote:
> Why remove the ability to make the configuration choice? Why not
> just add the info about performance impact to the help text and
> let me shoot myself in the foot (that is the unix way (tm)) if
> I desire to?
$ wc -l .config
2601 .config
It's too hard to get every single config option right ... unless it's a
works / doesn't work choice, having a "make my performance suck" config
option is a bad idea. I didn't even know I had this config option
set the wrong way until I ran powertop on my desktop, implemented its
recommendations for things I'd screwed up in my .config, then reran the
tests I was doing.
Someone with a big server might not run powertop, so wouldn't be
told they'd got it run. Sure, we could write a special tool to
check peoples config options to see if they've got some common
config options set wrongly ... but I'm rather reminded of Brazil.
http://farm1.static.flickr.com/50/109556460_5362c5f2b5_o.jpg
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Wed, Dec 22, 2010 at 1:34 PM, Matthew Wilcox <[email protected]> wrote:
>
> On Wed, Dec 22, 2010 at 01:00:37PM -0800, Frank Rowand wrote:
> > Why remove the ability to make the configuration choice? ?Why not
> > just add the info about performance impact to the help text and
> > let me shoot myself in the foot (that is the unix way (tm)) if
> > I desire to?
>
> $ wc -l .config
> 2601 .config
>
> It's too hard to get every single config option right ... unless it's a
> works / doesn't work choice, having a "make my performance suck" config
> option is a bad idea.
(And yet one more duplicate, because lkml rejected my previous reply. Sorry!!)
(sorry for the duplicate, I dropped the cc's on my previous reply)
Agreed that setting config options can be painful!
Various options that improve performance for your system can negatively impact
the performance of systems and applications that are different than your system.
On some of my real time systems, CONFIG_NO_HZ=y results in larger maximum
interrupts disabled values, meaning larger real time latency.
For the option in question, would it be sufficient to just add
"default y", so that the
common case gets the correct value, but the value remains configurable?
-Frank
On Dec 21 Matthew Wilcox wrote:
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -5,13 +5,9 @@ config TICK_ONESHOT
> bool
>
> config NO_HZ
> - bool "Tickless System (Dynamic Ticks)"
> + def_bool y
> depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
> select TICK_ONESHOT
> - help
> - This option enables a tickless system: timer interrupts will
> - only trigger on an as-needed basis both when the system is
> - busy and when the system is idle.
>
> config HIGH_RES_TIMERS
> bool "High Resolution Timer Support"
>
Even at a kconfig variable without prompt, a help section may be useful.
In case of this one, you should rather add to the text than remove it.
--
Stefan Richter
-=====-==-=- ==-- ==--=
http://arcgraph.de/sr/
> Why remove the ability to make the configuration choice? Why not
> just add the info about performance impact to the help text and
> let me shoot myself in the foot (that is the unix way (tm)) if
> I desire to?
One can argue that configurability is one of the greatest
strengths of Linux. OTOH, one can also argue that users
tend to get lost and hang themselves when given too
much rope; and that the burden of support and maintenance
of unnecessary config options squanders valuable resources.
Personally, I have two bugs filed against my code that
can be reproduced only in tickfull mode that almost
nobody uses. Is it a good use of my time to be
distracted by by configurations that 0.01% use,
or focus on issues seen by the other 99.99%?
I'm in favor of deleting the config option,
and the cmdline option with it, and I applaud
Matthew for proposing such.
Len Brown, Intel Open Source Technology Center
On Sun, 26 Dec 2010 17:22:40 -0500 (EST), you wrote:
>> Why remove the ability to make the configuration choice? Why not
>> just add the info about performance impact to the help text and
>> let me shoot myself in the foot (that is the unix way (tm)) if
>> I desire to?
>
>One can argue that configurability is one of the greatest
>strengths of Linux. OTOH, one can also argue that users
>tend to get lost and hang themselves when given too
>much rope; and that the burden of support and maintenance
>of unnecessary config options squanders valuable resources.
>
>Personally, I have two bugs filed against my code that
>can be reproduced only in tickfull mode that almost
>nobody uses. Is it a good use of my time to be
>distracted by by configurations that 0.01% use,
>or focus on issues seen by the other 99.99%?
>
>I'm in favor of deleting the config option,
>and the cmdline option with it, and I applaud
>Matthew for proposing such.
I always disable tickless since early on it crashed. I guess I haven't
bothered to risk that again, and, updating the kernel via 'make oldconfig'
means I'm not often presented with the option, apart from first custom
kernel after a new install.
There are many items in .cong need better help info, to inform on the
consequences, how we (the users) supposed to know the 'new' way is now
better than the old?
I'll try tickless, if only to gain back some unexpected performance loss on
a RAID6 system I built recently, I've not done RAID benchmarking for five
years ;) I expect twice the throughput I'm getting based on a Linux NAS
device I looked at recently.
I ask for the better help text, unless you can show tickful operation is
no longer required anywhere? A better help explanation plus scheduled
removal? (I didn't view the patch to know if that's what it does).
Grant.
>
>Len Brown, Intel Open Source Technology Center
Hi,
I have developed a device driver which is using default kernel work queue thread for deferring tasks. This work queue thread
while executing exits sometimes in function calls. It exits sometimes at one point and sometimes at another point without any panic. so the next time when the work is scheduled, it works normally.
can this problem be due to stack limit?
Regards
Raj
-
