login
Header Space

 
 

Feature: Robert Love Explains Variable HZ

October 15, 2002 - 11:17pm
Submitted by Jeremy on October 15, 2002 - 11:17pm.
Linux feature article

Robert Love [interview] recently backported the jiffies_to_clock_t() code from the 2.5 development kernel to the 2.4 stable kernel. This patch allows one to adjust the frequency of the timer interrupt, defined in the standard 2.4 kernel with HZ=100. In 2.5 this has been increased to HZ=1000.

I wrote Robert asking if he could explain the usefulness of his patch, and he replied in kind with a lengthy and very interesting email detailing what the patch is, how it works, and why it's useful. He explains, "The timer interrupt is at the heart of the system. Everything lives and dies based on it. Its period is basically the granularity of the system: timers hit on 10ms intervals, timeslices come due at 10ms intervals, etc."

Read on to learn what affect changing this value will have on your Linux server, and to see the actual patch...

Robert explains:

"I will start with what HZ is and then the ramifications of changing it... HZ is the frequency of the timer interrupt. In all versions of Linux until somewhere in the middle of 2.5, it was equal to 100 on x86 (most other architectures were also 100 - other are different, e.g alpha is 1024). So if HZ=100, the timer pops every 1/100 of a second or every 10ms.

"Recently in 2.5 we went to HZ=1000 on x86. Also, RedHat shipped their 8.0 kernel at HZ=512. So it is time to experiment...

"The timer interrupt is at the heart of the system. Everything lives and dies based on it. Its period is basically the granularity of the system: timers hit on 10ms intervals, timeslices come due at 10ms intervals, etc.

"There are important performance reasons for improving it: poll() and select() are timer-based, and you can get better performance by increasing HZ. I believe this was RedHat's rationale.

"There are also process response (i.e. latency) benefits. One good example would be process preemption: consider a process with 81ms remaining of its timeslice. It runs for 80ms, and now it has 1ms left. The timer interrupt hits. Now it continues running. In 1ms, it should be preempted, but it will continue running for 10ms, until the next timer interrupt hits.

"So there are a couple of reasons for changing HZ: better timer (and time in general) granularity, improved system latency, and improved poll()/select() performance. In general, the granularity of timing on the system improves whatever-fold you increase HZ by.

"There are downsides, however. The major one is the increased timer overhead. Going from HZ=100 to HZ=1000 you have 10x more timer interrupts and thus 10x overhead. Now, on a fast system, timer overhead is probably negligible to begin with. Ten times nothing is still nothing. But on a slower system (by slow I mean 386 or 486 slow) it may be an issue. The second issue is jiffie wraparound: the system uptime clock wraps around at about 497 days (32-bits holding 10 jiffies per second, 60 seconds in a minute, ...). If we go to HZ=1000, the uptime clock wraps in 49.7 days. We can fix this by backporting the 64-bit jiffies we have in 2.5 to 2.4, however.

"So with HZ=1000, the period of the timer interrupt is 1ms. System timing is 10x finer and things will have a granularity of 1ms. It seems to be showing an improvement in 2.5, and at least RedHat supposedly benched better poll/select performance.

"Without this patch, you cannot just change HZ, since the system exports various values via system call or /proc that are measured in ticks. In other words, things that are in the units of "ticks per seconds". And that depends on HZ. So we need a mechanism to scale the system HZ to the HZ user-space assumes, which is the traditional HZ=100. That is what jiffies_to_clock_t() does in 2.5 and what I backported."


From: Robert Love
To: linux-kernel mailing list
Subject: [PATCH] 2.4: variable HZ
Date: 	15 Oct 2002 02:03:02 -0400

I backported the jiffies_to_clock_t() code from 2.5 to 2.4, mostly just
for fun.

It works fine, and I have successfully used HZ=1000 on my machines.  It
is the same API as 2.5, used in the same places - we export a static
HZ=100 to user-space and convert from the real HZ as needed.  The only
difference is I added a CONFIG_HZ to allow the user to set the value.

There are probably some HZ values you cannot use due to NTP issues.  I
suggest HZ=1000, since I know that works, and 2.5 is using it.  RedHat
is supposedly shipping their kernel with HZ=512 but I do not know if
they did anything else special.

Oh, and I did not backport 64-bit jiffies yet.  So HZ=1000 will wrap
around in just under 50 days.  If you just cannot have that, stick with
a lower value.

Patch is against 2.4.20-pre10-ac2 but applies OK to all 2.4.20-pre and
2.4.19 kernels.

Enjoy,

	Robert Love

diff -urN linux-2.4.20-pre10-ac2/arch/i386/config.in linux/arch/i386/config.in
--- linux-2.4.20-pre10-ac2/arch/i386/config.in	2002-10-14 01:43:05.000000000 -0400
+++ linux/arch/i386/config.in	2002-10-14 18:24:48.000000000 -0400
@@ -244,6 +244,7 @@
 mainmenu_option next_comment
 comment 'General setup'
 
+int 'Timer frequency (HZ) (100)' CONFIG_HZ 100
 bool 'Networking support' CONFIG_NET
 
 # Visual Workstation support is utterly broken.
diff -urN linux-2.4.20-pre10-ac2/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.4.20-pre10-ac2/Documentation/Configure.help	2002-10-14 01:43:06.000000000 -0400
+++ linux/Documentation/Configure.help	2002-10-14 18:32:38.000000000 -0400
@@ -2411,6 +2411,18 @@
   behaviour is platform-dependent, but normally the flash frequency is
   a hyperbolic function of the 5-minute load average.
 
+Timer frequency
+CONFIG_HZ
+  The frequency the system timer interrupt pops.  Higher tick values provide
+  improved granularity of timers, improved select() and poll() performance,
+  and lower scheduling latency.  Higher values, however, increase interrupt
+  overhead and will allow jiffie wraparound sooner.  For compatibility, the
+  tick count is always exported as if HZ=100.
+
+  The default value, which was the value for all of eternity, is 100.  If
+  you are looking to provide better timer granularity or increased desktop
+  performance, try 500 or 1000.  In unsure, go with the default of 100.
+
 Networking support
 CONFIG_NET
   Unless you really know what you are doing, you should say Y here.
diff -urN linux-2.4.20-pre10-ac2/fs/proc/array.c linux/fs/proc/array.c
--- linux-2.4.20-pre10-ac2/fs/proc/array.c	2002-10-14 01:43:10.000000000 -0400
+++ linux/fs/proc/array.c	2002-10-14 18:24:48.000000000 -0400
@@ -360,15 +360,15 @@
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
-		task->times.tms_utime,
-		task->times.tms_stime,
-		task->times.tms_cutime,
-		task->times.tms_cstime,
+		jiffies_to_clock_t(task->times.tms_utime),
+		jiffies_to_clock_t(task->times.tms_stime),
+		jiffies_to_clock_t(task->times.tms_cutime),
+		jiffies_to_clock_t(task->times.tms_cstime),
 		priority,
 		nice,
 		0UL /* removed */,
-		task->it_real_value,
-		task->start_time,
+		jiffies_to_clock_t(task->it_real_value),
+		jiffies_to_clock_t(task->start_time),
 		vsize,
 		mm ? mm->rss : 0, /* you might want to shift this left 3 */
 		task->rlim[RLIMIT_RSS].rlim_cur,
@@ -686,14 +686,14 @@
 
 	len = sprintf(buffer,
 		"cpu  %lu %lun",
-		task->times.tms_utime,
-		task->times.tms_stime);
+		jiffies_to_clock_t(task->times.tms_utime),
+		jiffies_to_clock_t(task->times.tms_stime));
 		
 	for (i = 0 ; i per_cpu_utime[cpu_logical_map(i)],
-			task->per_cpu_stime[cpu_logical_map(i)]);
+			jiffies_to_clock_t(task->per_cpu_utime[cpu_logical_map(i)]),
+			jiffies_to_clock_t(task->per_cpu_stime[cpu_logical_map(i)]));
 
 	return len;
 }
diff -urN linux-2.4.20-pre10-ac2/fs/proc/proc_misc.c linux/fs/proc/proc_misc.c
--- linux-2.4.20-pre10-ac2/fs/proc/proc_misc.c	2002-10-14 01:43:10.000000000 -0400
+++ linux/fs/proc/proc_misc.c	2002-10-14 18:40:08.000000000 -0400
@@ -317,7 +317,7 @@
 {
 	int i, len = 0;
 	extern unsigned long total_forks;
-	unsigned long jif = jiffies;
+	unsigned long jif = jiffies_to_clock_t(jiffies);
 	unsigned int sum = 0, user = 0, nice = 0, system = 0;
 	int major, disk;
 
@@ -334,16 +334,19 @@
 	}
 
 	proc_sprintf(page, &off, &len,
-		      "cpu  %u %u %u %lun", user, nice, system,
+		      "cpu  %u %u %u %lun",
+		      jiffies_to_clock_t(user),
+		      jiffies_to_clock_t(nice),
+		      jiffies_to_clock_t(system),
 		      jif * smp_num_cpus - (user + nice + system));
 	for (i = 0 ; i 
+
+#ifdef __KERNEL__
+# define HZ		CONFIG_HZ	/* internal kernel timer frequency */
+# define USER_HZ	100		/* some user interfaces are in ticks */
+# define CLOCKS_PER_SEC	(USER_HZ)	/* like times() */
+# define jiffies_to_clock_t(x)	((x) / ((HZ) / (USER_HZ)))
+#endif
+
 #ifndef HZ
-#define HZ 100
+#define HZ 100				/* if userspace cheats, give them 100 */
 #endif
 
 #define EXEC_PAGESIZE	4096
@@ -17,8 +26,4 @@
 
 #define MAXHOSTNAMELEN	64	/* max length of hostname */
 
-#ifdef __KERNEL__
-# define CLOCKS_PER_SEC	100	/* frequency at which times() counts */
-#endif
-
 #endif
diff -urN linux-2.4.20-pre10-ac2/kernel/signal.c linux/kernel/signal.c
--- linux-2.4.20-pre10-ac2/kernel/signal.c	2002-10-14 01:43:11.000000000 -0400
+++ linux/kernel/signal.c	2002-10-14 18:24:49.000000000 -0400
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 /*
@@ -775,8 +775,8 @@
 	info.si_uid = tsk->uid;
 
 	/* FIXME: find out whether or not this is supposed to be c*time. */
-	info.si_utime = tsk->times.tms_utime;
-	info.si_stime = tsk->times.tms_stime;
+	info.si_utime = jiffies_to_clock_t(tsk->times.tms_utime);
+	info.si_stime = jiffies_to_clock_t(tsk->times.tms_stime);
 
 	status = tsk->exit_code & 0x7f;
 	why = SI_KERNEL;	/* shouldn't happen */
diff -urN linux-2.4.20-pre10-ac2/kernel/sys.c linux/kernel/sys.c
--- linux-2.4.20-pre10-ac2/kernel/sys.c	2002-10-14 01:43:11.000000000 -0400
+++ linux/kernel/sys.c	2002-10-14 18:24:49.000000000 -0400
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 
@@ -792,16 +792,23 @@
 
 asmlinkage long sys_times(struct tms * tbuf)
 {
+	struct tms temp;
+
 	/*
 	 *	In the SMP world we might just be unlucky and have one of
 	 *	the times increment as we use it. Since the value is an
 	 *	atomically safe type this is just fine. Conceptually its
 	 *	as if the syscall took an instant longer to occur.
 	 */
-	if (tbuf)
-		if (copy_to_user(tbuf, &current->times, sizeof(struct tms)))
+	if (tbuf) {
+		temp.tms_utime = jiffies_to_clock_t(current->times.tms_utime);
+		temp.tms_stime = jiffies_to_clock_t(current->times.tms_stime);
+		temp.tms_cutime = jiffies_to_clock_t(current->times.tms_cutime);
+		temp.tms_cstime = jiffies_to_clock_t(current->times.tms_cstime);
+		if (copy_to_user(tbuf, &temp, sizeof(struct tms)))
 			return -EFAULT;
-	return jiffies;
+	}
+	return jiffies_to_clock_t(jiffies);
 }
 
 /*


From: Robert Love Subject: Re: [PATCH] 2.4: variable HZ Date: 15 Oct 2002 02:50:56 -0400 On Tue, 2002-10-15 at 02:03, Robert Love wrote: > It works fine, and I have successfully used HZ=1000 on my machines. Except processor usage output was screwy. Attached is an updated patch which fixes the problem. Robert Love diff -urN linux-2.4.20-pre10-ac2/arch/i386/config.in linux/arch/i386/config.in --- linux-2.4.20-pre10-ac2/arch/i386/config.in 2002-10-14 01:43:05.000000000 -0400 +++ linux/arch/i386/config.in 2002-10-15 02:41:39.000000000 -0400 @@ -244,6 +244,7 @@ mainmenu_option next_comment comment 'General setup' +int 'Timer frequency (HZ) (100)' CONFIG_HZ 100 bool 'Networking support' CONFIG_NET # Visual Workstation support is utterly broken. diff -urN linux-2.4.20-pre10-ac2/Documentation/Configure.help linux/Documentation/Configure.help --- linux-2.4.20-pre10-ac2/Documentation/Configure.help 2002-10-14 01:43:06.000000000 -0400 +++ linux/Documentation/Configure.help 2002-10-15 02:41:40.000000000 -0400 @@ -2411,6 +2411,18 @@ behaviour is platform-dependent, but normally the flash frequency is a hyperbolic function of the 5-minute load average. +Timer frequency +CONFIG_HZ + The frequency the system timer interrupt pops. Higher tick values provide + improved granularity of timers, improved select() and poll() performance, + and lower scheduling latency. Higher values, however, increase interrupt + overhead and will allow jiffie wraparound sooner. For compatibility, the + tick count is always exported as if HZ=100. + + The default value, which was the value for all of eternity, is 100. If + you are looking to provide better timer granularity or increased desktop + performance, try 500 or 1000. In unsure, go with the default of 100. + Networking support CONFIG_NET Unless you really know what you are doing, you should say Y here. diff -urN linux-2.4.20-pre10-ac2/fs/proc/array.c linux/fs/proc/array.c --- linux-2.4.20-pre10-ac2/fs/proc/array.c 2002-10-14 01:43:10.000000000 -0400 +++ linux/fs/proc/array.c 2002-10-14 18:24:48.000000000 -0400 @@ -360,15 +360,15 @@ task->cmin_flt, task->maj_flt, task->cmaj_flt, - task->times.tms_utime, - task->times.tms_stime, - task->times.tms_cutime, - task->times.tms_cstime, + jiffies_to_clock_t(task->times.tms_utime), + jiffies_to_clock_t(task->times.tms_stime), + jiffies_to_clock_t(task->times.tms_cutime), + jiffies_to_clock_t(task->times.tms_cstime), priority, nice, 0UL /* removed */, - task->it_real_value, - task->start_time, + jiffies_to_clock_t(task->it_real_value), + jiffies_to_clock_t(task->start_time), vsize, mm ? mm->rss : 0, /* you might want to shift this left 3 */ task->rlim[RLIMIT_RSS].rlim_cur, @@ -686,14 +686,14 @@ len = sprintf(buffer, "cpu %lu %lun", - task->times.tms_utime, - task->times.tms_stime); + jiffies_to_clock_t(task->times.tms_utime), + jiffies_to_clock_t(task->times.tms_stime)); for (i = 0 ; i per_cpu_utime[cpu_logical_map(i)], - task->per_cpu_stime[cpu_logical_map(i)]); + jiffies_to_clock_t(task->per_cpu_utime[cpu_logical_map(i)]), + jiffies_to_clock_t(task->per_cpu_stime[cpu_logical_map(i)])); return len; } diff -urN linux-2.4.20-pre10-ac2/fs/proc/proc_misc.c linux/fs/proc/proc_misc.c --- linux-2.4.20-pre10-ac2/fs/proc/proc_misc.c 2002-10-14 01:43:10.000000000 -0400 +++ linux/fs/proc/proc_misc.c 2002-10-15 02:29:21.000000000 -0400 @@ -317,16 +317,16 @@ { int i, len = 0; extern unsigned long total_forks; - unsigned long jif = jiffies; + unsigned long jif = jiffies_to_clock_t(jiffies); unsigned int sum = 0, user = 0, nice = 0, system = 0; int major, disk; for (i = 0 ; i + +#ifdef __KERNEL__ +# define HZ CONFIG_HZ /* internal kernel timer frequency */ +# define USER_HZ 100 /* some user interfaces are in ticks */ +# define CLOCKS_PER_SEC (USER_HZ) /* like times() */ +# define jiffies_to_clock_t(x) ((x) / ((HZ) / (USER_HZ))) +#endif + #ifndef HZ -#define HZ 100 +#define HZ 100 /* if userspace cheats, give them 100 */ #endif #define EXEC_PAGESIZE 4096 @@ -17,8 +26,4 @@ #define MAXHOSTNAMELEN 64 /* max length of hostname */ -#ifdef __KERNEL__ -# define CLOCKS_PER_SEC 100 /* frequency at which times() counts */ -#endif - #endif diff -urN linux-2.4.20-pre10-ac2/kernel/signal.c linux/kernel/signal.c --- linux-2.4.20-pre10-ac2/kernel/signal.c 2002-10-14 01:43:11.000000000 -0400 +++ linux/kernel/signal.c 2002-10-14 18:24:49.000000000 -0400 @@ -13,7 +13,7 @@ #include #include #include - +#include #include /* @@ -775,8 +775,8 @@ info.si_uid = tsk->uid; /* FIXME: find out whether or not this is supposed to be c*time. */ - info.si_utime = tsk->times.tms_utime; - info.si_stime = tsk->times.tms_stime; + info.si_utime = jiffies_to_clock_t(tsk->times.tms_utime); + info.si_stime = jiffies_to_clock_t(tsk->times.tms_stime); status = tsk->exit_code & 0x7f; why = SI_KERNEL; /* shouldn't happen */ diff -urN linux-2.4.20-pre10-ac2/kernel/sys.c linux/kernel/sys.c --- linux-2.4.20-pre10-ac2/kernel/sys.c 2002-10-14 01:43:11.000000000 -0400 +++ linux/kernel/sys.c 2002-10-14 18:24:49.000000000 -0400 @@ -15,7 +15,7 @@ #include #include #include - +#include #include #include @@ -792,16 +792,23 @@ asmlinkage long sys_times(struct tms * tbuf) { + struct tms temp; + /* * In the SMP world we might just be unlucky and have one of * the times increment as we use it. Since the value is an * atomically safe type this is just fine. Conceptually its * as if the syscall took an instant longer to occur. */ - if (tbuf) - if (copy_to_user(tbuf, &current->times, sizeof(struct tms))) + if (tbuf) { + temp.tms_utime = jiffies_to_clock_t(current->times.tms_utime); + temp.tms_stime = jiffies_to_clock_t(current->times.tms_stime); + temp.tms_cutime = jiffies_to_clock_t(current->times.tms_cutime); + temp.tms_cstime = jiffies_to_clock_t(current->times.tms_cstime); + if (copy_to_user(tbuf, &temp, sizeof(struct tms))) return -EFAULT; - return jiffies; + } + return jiffies_to_clock_t(jiffies); } /*



Related links:

  • KernelTrap Interview With Robert Love
  • Google Archive Of Above Thread
  • This will benefit latency mainly.

    October 16, 2002 - 2:27am

    Where pure latency is concerned, this patch makes a difference. Audio/Video sampling and playback is a perfect example of this, and avoiding dropouts. In terms of system responsiveness though, humans are not able to detect resolution below 1/100 of a second (the 2.4 interrupt Hz). I have tried this patch with -ck9 and 512 and 1000Hz and did not feel any difference, and the contest benchmarks were ever so slightly slower but not statistically significant. On a high spec machine as RML has said, there may be performance advantages (not system responsiveness as such).

    Jiffy wrap around

    October 16, 2002 - 9:14am
    Anonymous

    Does anyone know what happens when the jiffies actually wrap? How does an event that happens every 497 is not a problem while when it happens every 49.7 days it is. Seems a bit sloppy to me. Either it is wrong or not. Of course using 64bit values effectively solves the problem.

    Jiffy effect

    October 16, 2002 - 9:19am

    It simply means that after 497 days your uptime will reset to 0 days. If you make the resolution 1000Hz your uptime will reset after only 49.7 days. It is not harmful.

    Hopefully isn't harmful

    October 16, 2002 - 11:37am
    Anonymous

    Certainly in the past, various drivers would rely on the jiffy value always being greater than the previous value, and wouldn't correctly deal with the jiffy counter wrapping round. I presume most (if not all) of these places are now fixed, but there's still at least the potential for problems in drivers.

    Re: Hopefully isn't harmful

    October 16, 2002 - 1:26pm

    Most code (ideally all) has switched to using the safe time_after and time_before macros that check for wrap-around.

    Some may not, however. I plan on back-porting the 64-bit jiffies to 2.4.. if the 49.7 days is a problem then I would suggest not setting HZ so high.

    Why not use a constant to sta

    October 16, 2002 - 2:37pm
    Anonymous

    Why not use a constant to start the jiffies.
    We could acheive a jiffie wrap within one hour from boot time, or whatever seems resonable.
    This way we will break things that depend on the jiffies quite fast, instead of having to find out in one and a half month.

    /Magnus

    I think that is a great idea.

    October 16, 2002 - 3:21pm
    Anonymous

    I think that is a great idea. A couple years ago (during 2.3 I think), someone suggested the same thing on LKML. They suggested that jiffies not start at 0, but 0 - 10 minutes. That way wraparound bugs would be found much more often.

    I believe Linus refused to make the change because it would only create more work (debugging) and that jiffy wraparound was rare enough to not really matter (because at the time it took 497 days). Good luck having Linux uptime > 497 days. Now 49.7 days is a much more likely story..

    Maybe someone should make this suggestion on LKML again.

    Uptime >= 497 days

    October 16, 2002 - 3:38pm

    Good luck having Linux uptime > 497 days. Now 49.7 days is a much more likely story..

    If my memory is correct, there was a post to lkml last year or so where a 2.2 user had observed an incorrect uptime after his uptime exceeded 497 days. So, it may be unlikely, but it certainly ain't impossible. :)

    Apart from that, I do agree that deliberately causing a jiffie wraparound to find bugs in the kernel would be a good idea, but at the same time, 64-bit jiffies should also definitely be backported to 2.4 IMO.

    --
    schnee

    uptime = 497 days

    October 17, 2002 - 5:09am
    Anonymous

    I had a 2.0.3x something that was up for 497 days and then crashed dumping registers to the screen.

    At the time I didn't know about the jiffies wrap around and I can't be sure the crash had something to do with it either.

    We also had a win95 machine we used for burning cd's which we never rebooted and it would crash every 49 days, that was a bug that got fixed by microsoft layer on. Does win95 have a jiffies of about a 1000 or is this another bug?

    Regards
    Magnus

    uptime = 497 days (Win95 uptime 49 days)

    October 17, 2002 - 7:00am
    Anonymous

    It's the same sort of thing in Win95 - there is a millisecond counter that runs over. It is used for all sorts of timing purposes in Win95, so it is more of a problem than a simple uptime count. As far as I understand it, there are timer interrupts running at 1000 Hz (for this millisecond counter), but many timing functions (such as time-slicing, or software timers) run at 50 or 60 Hz.

    497 day uptime

    October 17, 2002 - 4:48pm
    Anonymous

    I've had an uptime of over 497 days on a couple of 2.0.x servers. The uptime counter wrapped to 0, but the system operation continued flawlessly. I think the highest I've seen is an uptime of about 180 days - after it wrapped around at 497. It definately didn't cause any sort of driver instability.

    uptime wraparound

    July 10, 2007 - 10:51am
    Anonymous (not verified)

    Does anyone know if the uptime counter wraparound problem (reset to 0 after 495 days) was fixed in RHEL 4? My kernel version is 2.6.9. Thanks!

    We already have ....

    October 18, 2002 - 1:27am
    Anonymous

    We already have 64bit jiffies patch :)
    http://www.physik3.uni-rostock.de/tim/kernel/2.4/

    Regards

    other uses of this feature

    October 16, 2002 - 10:41am
    Anonymous

    Does this mean that if you are doing some serious number crunching lasting for a long time (i.e. static number of processes needing lots of CPU time for days/weeks etc) then setting HZ to a number lower than 100 would increase performance? I'd imagine that if timeslices are increased then you'd see higher throughput (less context switches occurring), is that correct?

    Not quite

    October 16, 2002 - 10:46am

    The amount of wasted cpu cycles by an interrupt every 1/100 of a second would not amount to much even over days, so it probably wouldn't make a difference. Furthermore if you reduce it too much the cpu will be waiting to be told when to do it's next task thereby wasting cpu time so reducing it will be of no benefit.

    Re: other uses of this feature

    October 16, 2002 - 1:28pm

    I guess so, but for the same reason I say HZ=1000 is not too high overhead I suspect HZ less than 100 is not too much savings.

    Also timeslices != HZ... you can increase those by setting MAX_TIMESLICE to a larger value in kernel/sched.c (for the O(1) scheduler). But I think the default maximum timeslice is sufficient... if you have other tasks to run, they should run, otherwise your number-crunching application will monopolize the processor on its own. Set its nice high and let it roll...

    timeslice != 1/HZ

    October 17, 2002 - 5:32pm
    Anonymous

    You're making a possibly invalid assumption -- that a process touches a large portion of its working set every timeslice. I don't think that's terribly likely for many interesting workloads. (Ok, maybe bloatmonsters like Mozilla and X do.) Also, as pointed out elsewhere, don't confuse timeslice with granularity: The timeslices didn't get shorter, just our resolution for setting them and enforcing them.

    If apps thrashed out their working set every slice, then why bother with CPU affinity at all?

    patch

    October 16, 2002 - 4:58pm

    Is there a direct link to this patch?

    Thanks.

    Re: patch

    October 16, 2002 - 5:45pm

    whoops...

    October 16, 2002 - 5:53pm

    Er, wrong patch. Too many on kerneltrap today ;-)

    No, its not up anywhere... let me put it up... OK it should be up at
    http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ as soon as the mirrors sync.

    thanks!!

    October 16, 2002 - 8:06pm

    I actually looked there for your patch first (before I made the post here on kerneltrap.org) so it's good to know I wasn't going crazy and was just not seeing it.

    Thanks!

    HZ-less patch

    October 20, 2002 - 11:01am
    Anonymous

    I saw once a patch that completely removed HZ. (I think it was part of a soft realtime project.) It worked, IIRC, by at each exit to userspace calculating when the next timer interrupt is needed (to wake a process from a usleep, to preempt a process, etc.) and dynamically setting the timer resolution to that.

    Is something like that likely to be merged in the future? Why or why not?

    Re: HZ-less patch

    October 20, 2002 - 1:52pm

    Probably not. The overhead was killer.

    The patch was written by a co-worker as an experiment - the result was a tickless system is pretty hard to get right with the timer overhead.

    Variable HZ patch and 64-bit jiffies?

    October 23, 2002 - 8:43am
    Anonymous

    Has anyone managed to get this patch and the 64-bit jiffies one (http://www.physik3.uni-rostock.de/tim/kernel/2.4/) working together?

    testing settings

    October 23, 2002 - 4:28pm
    Anonymous

    There must be a snippet of code to test it made it into the running
    kernel?? Or does it show up in /proc somewhere
    Anyone want to share?
    thanks,

    Re: testing settings

    October 24, 2002 - 3:47am

    There must be a snippet of code to test it made it into the running
    kernel?

    Do vmstat 1 on an idle system. Under "in" is the number of interrupts your system has received in the last second. On an idle system, you should not receive much other than the timer interrupt. Maybe -/+ 10%. So if it is ~100 you have HZ=100 and if it is ~1000 you have HZ=1000.

    But you really do not need to prove it to yourself that the HZ change was made. It was.

    I believe in the patch just n

    October 28, 2002 - 9:24pm
    Anonymous

    I believe in the patch just never sure if I grub'ed the correct kernel. Thanks for the vmstat 1.

    vmstat ANY fits

    February 18, 2003 - 10:21am
    Anonymous

    vmstat ANY fits, actually. man vmstat if guessing why.

    What about I/O?

    January 10, 2003 - 12:22am
    Anonymous

    I'm been trying to optimize a couple of programs that communicate throught the serial port (multiple process both on the client and server side). This patch has make a BIG difference, reducing the communication time between the local processes 10 times!!

    However, it looks like the patch didn't affect the I/O schedulers, because the process who listen the serial port can make a read operation only every 10 ms! (checked on the oscilloscope with both kernels)

    Is this patch ony for the CPU scheduler?? Someone knows a patch to do the same thing for the I/O schedullers??

    Thanks

    local uptime fixed, nmap still shows a wrap back to 0.

    February 20, 2003 - 11:37pm
    Anonymous

    I am running the 2.5.62 development kernel on my play server. I created a small patch which allows me to manipulate the uptime to test the 497 day rollover issue. It seems that now the "uptime" command is working properly and will not roll back to 0 after 497 days. "nmap", however still shows the uptime wrap back to 0 after 497 days. I am curious if this is an "nmap" issue or a TCP/IP stack issue in the Linux kernel?

    [hostA]$ uname -r
    2.5.62
    [hostA]$ uptime
    496 days

    [hostB]# nmap -sS -O hostA
    496 days

    [hostA]$ uptime
    498 days

    [hostB]# nmap -sS -O hostA
    1 day

    FC5 2.6 Kernel

    August 25, 2006 - 1:54pm
    Elliot (not verified)

    I am running 2.6.17-1.2174_FC5 32Bit and i am wondering if i can use this, or if there is something else available for chaging the kernel clock to 1000 without recompiling. I have never done anything with a kernel before so i am just looking for a simple solution.

    Thanks

    Elliot

    FC5 2.6 Kernel

    August 25, 2006 - 2:13pm

    I am running 2.6.17-1.2174_FC5 32Bit and i am wondering if i can use this, or if there is something else available for chaging the kernel clock to 1000 without recompiling. I have never done anything with a kernel before so i am just looking for a simple solution.

    Thanks

    Elliot

    Your linux kernel is running

    September 5, 2006 - 3:37am
    Anonymous (not verified)

    Your linux kernel is running with HZ=1000, so you need not
    to recompile your kernel

    How to check Kernel Frequency

    September 11, 2006 - 10:50am
    yuenho (not verified)

    Hi, I installed a vanilla 64 bit FC5, how do I check my kernel frequency? Is there a command? I'm looking around for a fix for my Counterstrike:S server, which tends to drop in ticks once a few users connect.

    variable HZ patch for linux-2.4.31

    January 17, 2007 - 5:26am
    Teh Kok How (not verified)

    Hi;
    Is there any variable HZ patch for linux-2.4.31? I don't find it in http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ/v2.4/
    Thanks.

    Regards,
    KH

    Minor typo I

    April 1, 2008 - 12:05pm
    Anonymous (not verified)

    Minor typo I believe:
    "(32-bits holding 10 jiffies per second, 60 seconds in a minute, ...)."
    shouuld be
    "(32-bits holding 100 jiffies per second, 60 seconds in a minute, ...)."

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.
    speck-geostationary