[lkml]   [2001]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: #define HZ 1024 -- negative effects?
On Wed, Apr 25, 2001 at 10:02:26PM -0400, Dan Maas wrote:

> > Are there any negative effects of editing include/asm/param.h to change
> > HZ from 100 to 1024? Or any other number? This has been suggested as a
> > way to improve the responsiveness of the GUI on a Linux system.
> Of course, the appearance of better interactivity could just be a placebo
> effect. Double-blind trials, anyone? =)

I tried HZ=1024 on my i386 kernel, to check two things. One was a timer
routine. The performance of the timer routine depends heavily on the
granularity of the nanosleep() or select() system call. Since those calls
always block at least 1/HZ seconds, the timer precision indeed increased by a
factor 10 when I changed the HZ value from 100 to 1024.

However, another thing I wanted to do was to generate profiling statistics for
freesci. Profiling is done with 1/HZ granularity. Any subroutine in a program
executed in less than 1/HZ cannot be profiled correctly (for example a routine
that executes in 1 nanosecond and one that needs 1/HZ/2 seconds both show up
as taking 1 sample).

Now, you would think that profiling would be a lot better with HZ=1024.
However, the program didn't even run anymore! The reason is that some system
calls are being interupted by SIGPROF every 1/HZ, and return something like
ERESTARTSYS to the libraries. The libraries then try to restart the system
call but a SIGPROF is bound to follow shortly, again interrupting the system
call, and so on...

Met vriendelijke groet / with kind regards,
Guus Sliepen <>
See also:
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 12:52    [W:2.478 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site