[ckpatch][15/29] hz-no_default_250.patch

[ckpatch][15/29] hz-no_default_250.patch

[Con Kolivas]

Make 250 HZ a value that is not selected by default and give some better
recommendations in help.

Signed-off-by: Con Kolivas <kernel@kolivas.org>

 kernel/Kconfig.hz |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)

Index: linux-ck-dev/kernel/Kconfig.hz
===================================================================
--- linux-ck-dev.orig/kernel/Kconfig.hz	2006-06-18 15:23:58.000000000 +1000
+++ linux-ck-dev/kernel/Kconfig.hz	2006-06-18 15:24:28.000000000 +1000
@@ -21,14 +21,17 @@ choice
 	help
 	  100 HZ is a typical choice for servers, SMP and NUMA systems
 	  with lots of processors that may show reduced performance if
-	  too many timer interrupts are occurring.
+	  too many timer interrupts are occurring. Laptops may also show
+	  improved battery life.
 
-	config HZ_250
+	config HZ_250_NODEFAULT
 		bool "250 HZ"
 	help
-	 250 HZ is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems.
+	 250 HZ is a lousy compromise choice allowing server interactivity
+	 while also showing desktop throughput and no extra power saving on
+	 laptops. Good for when you can't make up your mind.
+
+	 Recommend 100 or 1000 instead.
 
 	config HZ_1000
 		bool "1000 HZ"
@@ -41,6 +44,6 @@ endchoice
 config HZ
 	int
 	default 100 if HZ_100
-	default 250 if HZ_250
+	default 250 if HZ_250_NODEFAULT
 	default 1000 if HZ_1000
 

-- 
-ck

Re: [ckpatch][15/29] hz-no_default_250.patch

[Willy Tarreau]

Hi Con,

On Sun, Jun 18, 2006 at 05:32:48PM +1000, Con Kolivas wrote:
> Make 250 HZ a value that is not selected by default and give some better
> recommendations in help.
> 
> Signed-off-by: Con Kolivas <kernel@kolivas.org>
> 
>  kernel/Kconfig.hz |   15 +++++++++------
>  1 files changed, 9 insertions(+), 6 deletions(-)
> 
> Index: linux-ck-dev/kernel/Kconfig.hz
> ===================================================================
> --- linux-ck-dev.orig/kernel/Kconfig.hz	2006-06-18 15:23:58.000000000 +1000
> +++ linux-ck-dev/kernel/Kconfig.hz	2006-06-18 15:24:28.000000000 +1000
> @@ -21,14 +21,17 @@ choice
>  	help
>  	  100 HZ is a typical choice for servers, SMP and NUMA systems
>  	  with lots of processors that may show reduced performance if
> -	  too many timer interrupts are occurring.
> +	  too many timer interrupts are occurring. Laptops may also show
> +	  improved battery life.
>  
> -	config HZ_250
> +	config HZ_250_NODEFAULT
>  		bool "250 HZ"
>  	help
> -	 250 HZ is a good compromise choice allowing server performance
> -	 while also showing good interactive responsiveness even
> -	 on SMP and NUMA systems.
> +	 250 HZ is a lousy compromise choice allowing server interactivity
> +	 while also showing desktop throughput and no extra power saving on
> +	 laptops. Good for when you can't make up your mind.
> +
> +	 Recommend 100 or 1000 instead.

In fact, I use this value (250 Hz) on servers because it provides slightly
finer scheduling precision than 100 Hz without the performance impact of
1000 Hz. It also has the advantage that conversions between ms<->jiffies
are performed by bit shifts only and no divide nor multiply. I really do
not notice any performance hit between 100 and 250 Hz, while I do between
250 and 1000.

Cheers,
Willy

Re: [ckpatch][15/29] hz-no_default_250.patch

[Con Kolivas]

On Sunday 18 June 2006 17:42, Willy Tarreau wrote:
> Hi Con,
>
> On Sun, Jun 18, 2006 at 05:32:48PM +1000, Con Kolivas wrote:
> > Make 250 HZ a value that is not selected by default and give some better
> > recommendations in help.
> >
> > Signed-off-by: Con Kolivas <kernel@kolivas.org>
> >
> >  kernel/Kconfig.hz |   15 +++++++++------
> >  1 files changed, 9 insertions(+), 6 deletions(-)
> >
> > Index: linux-ck-dev/kernel/Kconfig.hz
> > ===================================================================
> > --- linux-ck-dev.orig/kernel/Kconfig.hz	2006-06-18 15:23:58.000000000
> > +1000 +++ linux-ck-dev/kernel/Kconfig.hz	2006-06-18 15:24:28.000000000
> > +1000 @@ -21,14 +21,17 @@ choice
> >  	help
> >  	  100 HZ is a typical choice for servers, SMP and NUMA systems
> >  	  with lots of processors that may show reduced performance if
> > -	  too many timer interrupts are occurring.
> > +	  too many timer interrupts are occurring. Laptops may also show
> > +	  improved battery life.
> >
> > -	config HZ_250
> > +	config HZ_250_NODEFAULT
> >  		bool "250 HZ"
> >  	help
> > -	 250 HZ is a good compromise choice allowing server performance
> > -	 while also showing good interactive responsiveness even
> > -	 on SMP and NUMA systems.
> > +	 250 HZ is a lousy compromise choice allowing server interactivity
> > +	 while also showing desktop throughput and no extra power saving on
> > +	 laptops. Good for when you can't make up your mind.
> > +
> > +	 Recommend 100 or 1000 instead.
>
> In fact, I use this value (250 Hz) on servers because it provides slightly
> finer scheduling precision than 100 Hz without the performance impact of
> 1000 Hz. It also has the advantage that conversions between ms<->jiffies
> are performed by bit shifts only and no divide nor multiply. I really do
> not notice any performance hit between 100 and 250 Hz, while I do between
> 250 and 1000.

Thanks for your perspective. I found performance hits on computational tasks 
with 250 vs 100 but your finer precision makes perfect sense.

-- 
-ck

Re: [ckpatch][15/29] hz-no_default_250.patch

[Jan Engelhardt]

>
>Thanks for your perspective. I found performance hits on computational tasks 
>with 250 vs 100 but your finer precision makes perfect sense.
>

Or this one so every user can set any value s/he wants. :)

Done-by: Me.

diff --fast -Ndpru linux-2.6.17-rc6~/kernel/Kconfig.hz linux-2.6.17-rc6+/kernel/Kconfig.hz
--- linux-2.6.17-rc6~/kernel/Kconfig.hz	2006-06-06 02:57:02.000000000 +0200
+++ linux-2.6.17-rc6+/kernel/Kconfig.hz	2006-06-16 17:15:46.884794000 +0200
@@ -2,45 +2,26 @@
 # Timer Interrupt Frequency Configuration
 #
 
-choice
-	prompt "Timer frequency"
-	default HZ_250
-	help
-	 Allows the configuration of the timer frequency. It is customary
-	 to have the timer interrupt run at 1000 HZ but 100 HZ may be more
-	 beneficial for servers and NUMA systems that do not need to have
-	 a fast response for user interaction and that may experience bus
-	 contention and cacheline bounces as a result of timer interrupts.
-	 Note that the timer interrupt occurs on each processor in an SMP
-	 environment leading to NR_CPUS * HZ number of timer interrupts
-	 per second.
-
-
-	config HZ_100
-		bool "100 HZ"
-	help
-	  100 HZ is a typical choice for servers, SMP and NUMA systems
-	  with lots of processors that may show reduced performance if
-	  too many timer interrupts are occurring.
-
-	config HZ_250
-		bool "250 HZ"
-	help
-	 250 HZ is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems.
-
-	config HZ_1000
-		bool "1000 HZ"
-	help
-	 1000 HZ is the preferred choice for desktop systems and other
-	 systems requiring fast interactive responses to events.
+config HZ
+    int "Timer frequency"
+    default 100
+    ---help---
+        Allows the configuration of the timer frequency. It is
+        customary to have the timer interrupt run at 1000 HZ but 100 HZ
+        may be more beneficial for servers and NUMA systems that do not
+        need to have a fast response for user interaction and that may
+        experience bus contention and cacheline bounces as a result of
+        timer interrupts.  Note that the timer interrupt occurs on each
+        processor in an SMP environment leading to NR_CPUS * HZ number
+        of timer interrupts per second.
 
-endchoice
+        100 HZ is a typical choice for servers, SMP and NUMA systems
+        with lots of processors that may show reduced performance if
+        too many timer interrupts are occurring.
 
-config HZ
-	int
-	default 100 if HZ_100
-	default 250 if HZ_250
-	default 1000 if HZ_1000
+        250 HZ is a good compromise choice allowing server performance
+        while also showing good interactive responsiveness even on SMP
+        and NUMA systems.
 
+        1000 HZ is the preferred choice for desktop systems and other
+        systems requiring fast interactive responses to events.
#<<eof>>



Jan Engelhardt
-- 

Re: [ckpatch][15/29] hz-no_default_250.patch

[Albert Cahalan]

> Make 250 HZ a value that is not selected by default and give some
> better recommendations in help.

No, 250 is a good default.

We can't reliably do 1000. There are many systems, including both
laptops and servers, which have a BIOS that uses SMM/SMI to grab
the CPU for longer than a millisecond. We'd lose clock ticks if
we had HZ at 1000.

NTSC video is 59.94 fields per second. Though a sample rate of
double that would satisfy the Nyquest theory, in practice you
need to go to 4x to 5x the rate you want. This comes out to be
around 240 to 300 as a minimum.

Then there is the matter of picking a value that is very close
to being an integer factor of the standard PC clock. I don't
remember how well 250 did, but here is the code I once used
to compute such things:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <float.h>
#include <math.h>

// 1189200.0 // AMD ELAN
// 1193182.0 // normal

#define PITHZ 1193182.0

double nearbyint(double x);

#define TARGET_MAX 1300 // was 15000
#define TARGET_MIN 240  // was 9

int main(int argc, char *argv[]){
  unsigned target = TARGET_MAX;
  while(--target>TARGET_MIN){
st:;
    unsigned setting = nearbyint(PITHZ / target);
    double actual = PITHZ / setting;
    double diff = actual - target;
    double perc = 100.0*diff/target;
//    if(target & 3) continue;
#if 1
    if(target!=1000 && target !=1024 && target!=100 && target!=400 &&
target!=600
      && target!=1200 && target!=240 && target!=300 && target!=800
      && target!=512 && target!=256 && target!=128)
      if(perc > 0.01 || perc < -0.01) continue;
#else
    {
    if(perc>-0.6 && perc<0.6) continue;
    }
#endif
    printf("%+11.8f %+10.6f %6u %5u %12.6f\n", perc, diff, setting,
target, actual);
  }
  if(target>105) {
    target = 100;
    goto st;
  }
  return 0;
}

Re: [ckpatch][15/29] hz-no_default_250.patch

[Con Kolivas]

On Monday 19 June 2006 10:52, Albert Cahalan wrote:
> > Make 250 HZ a value that is not selected by default and give some
> > better recommendations in help.
>
> No, 250 is a good default.
>
> We can't reliably do 1000. There are many systems, including both
> laptops and servers, which have a BIOS that uses SMM/SMI to grab
> the CPU for longer than a millisecond. We'd lose clock ticks if
> we had HZ at 1000.

We do not lost clock ticks on ordinary desktops at HZ==1000 which is what I'm 
recommending here. For servers and laptops I'm recommending 100.

> NTSC video is 59.94 fields per second. Though a sample rate of
> double that would satisfy the Nyquest theory, in practice you
> need to go to 4x to 5x the rate you want. This comes out to be
> around 240 to 300 as a minimum.

Yes I understand that but there is also the matter that we don't guarantee 
timers actually even succeed at the HZ value. In practice our timers, even at 
almost no load, only can guarantee firing 2 or 3 ticks after the time we 
requested. This means we need timers to be about 3x higher than the 250 we 
need.

> Then there is the matter of picking a value that is very close
> to being an integer factor of the standard PC clock. I don't
> remember how well 250 did, but here is the code I once used
> to compute such things:

Yes I stored a family of these values and 864 was ~ the optimum for a high 
value for desktops and ~84 for a low value but were unpopular for not being 
something decimally familiar. Also lots of code kind of broke with values 
below 100 in the kernel.

Thanks!

-- 
-ck

Re: [ckpatch][15/29] hz-no_default_250.patch

[Jan Engelhardt]

>
>Yes I stored a family of these values and 864 was ~ the optimum for a high 
>value for desktops and ~84 for a low value but were unpopular for not being 

82 IIRC.

>something decimally familiar. Also lots of code kind of broke with values 
>below 100 in the kernel.

Ought to be fixed. Just like the code which assumed 100 Hz and broke during 
the initial switch to 1000, before we went back again to 250. :p


Jan Engelhardt
-- 

Re: [ckpatch][15/29] hz-no_default_250.patch

[Con Kolivas]

On Monday 19 June 2006 21:52, Jan Engelhardt wrote:
> >Yes I stored a family of these values and 864 was ~ the optimum for a high
> >value for desktops and ~84 for a low value but were unpopular for not
> > being
>
> 82 IIRC.

Ah yes here it is

    HZ   ticks/jiffie  1 second      error (ppm)
---------------------------------------------------
    82      14551      1.000000152       0.2
    96      12429      1.000001829       1.8
   209       5709      0.999999314      -0.7
   363       3287      0.999999314      -0.7
   519       2299      0.999999314      -0.7
   864       1381      1.000001829       1.8

>
> >something decimally familiar. Also lots of code kind of broke with values
> >below 100 in the kernel.
>
> Ought to be fixed. Just like the code which assumed 100 Hz and broke during
> the initial switch to 1000, before we went back again to 250. :p

No impetus to fix them I guess since there is no way to configure the kernel 
for sub 100 HZ configs without hacking it.

-- 
-ck

Re: [ckpatch][15/29] hz-no_default_250.patch

[Lee Revell]

On Sun, 2006-06-18 at 20:52 -0400, Albert Cahalan wrote:
> > Make 250 HZ a value that is not selected by default and give some
> > better recommendations in help.
> 
> No, 250 is a good default.
> 
> We can't reliably do 1000. There are many systems, including both
> laptops and servers, which have a BIOS that uses SMM/SMI to grab
> the CPU for longer than a millisecond. We'd lose clock ticks if
> we had HZ at 1000.
> 

Doesn't this become a non-issue with John Stultz's gettimeofday rework?

> NTSC video is 59.94 fields per second. Though a sample rate of
> double that would satisfy the Nyquest theory, in practice you
> need to go to 4x to 5x the rate you want. This comes out to be
> around 240 to 300 as a minimum.

Realtime audio wants higher framerates than video.  Of course many of
these systems with the SMM bug are fatally broken for these
applications.

Lee

Re: [ckpatch][15/29] hz-no_default_250.patch

[Con Kolivas]

On Monday 19 June 2006 11:30, Lee Revell wrote:
> On Sun, 2006-06-18 at 20:52 -0400, Albert Cahalan wrote:
> > > Make 250 HZ a value that is not selected by default and give some
> > > better recommendations in help.
> >
> > No, 250 is a good default.
> >
> > We can't reliably do 1000. There are many systems, including both
> > laptops and servers, which have a BIOS that uses SMM/SMI to grab
> > the CPU for longer than a millisecond. We'd lose clock ticks if
> > we had HZ at 1000.
>
> Doesn't this become a non-issue with John Stultz's gettimeofday rework?

No, but Thomas Gleixner's HRTimers will. Also the extra granularity in the cpu 
scheduler is desirable on a desktop.
>
> > NTSC video is 59.94 fields per second. Though a sample rate of
> > double that would satisfy the Nyquest theory, in practice you
> > need to go to 4x to 5x the rate you want. This comes out to be
> > around 240 to 300 as a minimum.
>
> Realtime audio wants higher framerates than video.  Of course many of
> these systems with the SMM bug are fatally broken for these
> applications.

Agreed.

-- 
-ck