login
Search
Jean-Marc Valin offered a patch on the lkml against the 2.6.0-test11 kernel [story] adding the ability to increase the HZ all the way up to 10,000. In an earlier discussion about variable hertz [story], Robert Love [interview] talked about the impact of the 2.6 kernel increasing the default HZ from 100 up to 1000. Robert then explained, "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." On the plus side, Robert also then described how you can get better performance with a higher HZ.
When asked why he needed a 10x increase to the already increased default 2.6 HZ setting, Jean-Marc humorously explained that he didn't like the CPU's ~1kHz idle sound, prefering instead to increase it to 10kHz, "a frequency where the ear is much less sensitive." This explanation lead to a quip from Nick Piggin [interview], "Does it scare your dog away?", as well as a pointer from Tim Schmielau to other high-res-timer patches.
From: Jean-Marc Valin [email blocked] To: Linux Kernel [email blocked] Subject: Increasing HZ (patch for HZ > 1000) Date: Thu, 11 Dec 2003 01:05:42 -0500 Hi, I think this may be of interest to some people. I've attached a patch that makes it possible to increase HZ up to 10000. The patch adds some HZ-related defines (e.g. SHIFT_HZ) for higher HZ values. It also removes some shift by negative number and divide by zero (e.g. in bogomips computation) and prevents some overflows. I'm not sure I fixed everything, but right now it seems to work with HZ=10000. The only thing I'm seeing are messages such as: "orinoco_lock() called with hw_unavailable (dev=f75c8000)" and "eth1: IRQ handler is looping too much! Resetting.". I know it's (much) too late for 2.6 but I'm sending the patch anyway so it (hopefully) doesn't get lost. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada [hz.patch]
From: Martin J. Bligh [email blocked] Subject: Re: Increasing HZ (patch for HZ > 1000) Date: Wed, 10 Dec 2003 23:07:19 -0800 Why would you want to *increase* HZ? I'd say 1000 is already too high personally, but I'm curious what you'd want to do with it? Embedded real-time stuff? M.
From: Jean-Marc Valin [email blocked] Subject: Re: Increasing HZ (patch for HZ > 1000) Date: Thu, 11 Dec 2003 02:15:29 -0500 Actually, my reasons may sound a little strange, but basically I'd be fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the sound is at a frequency where the ear is much less sensitive. Anyway, I thought some people might be interested in high HZ for other (more fundamental) reasons, so I posted the patch. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada
From: Martin J. Bligh [email blocked] Subject: Re: Increasing HZ (patch for HZ > 1000) Date: Wed, 10 Dec 2003 23:18:20 -0800 Ha! ;-) A hardware fix might be in order ;-) M.
From: Nick Piggin [email blocked] Subject: Re: Increasing HZ (patch for HZ > 1000) Date: Thu, 11 Dec 2003 18:30:06 +1100 Heh! Does it scare your dog away? ;)
From: Tim Schmielau [email blocked] Subject: Re: Increasing HZ (patch for HZ > 1000) Date: Thu, 11 Dec 2003 09:25:24 +0100 (CET) =8-) I'd guess a tickless kernel might be what you actually want. See e.g. http://sourceforge.net/projects/high-res-timers/ Tim
Hz
Just wondering, why does everyone spell it "HZ"?
The correct "capitalization" for the SI frequency unit is "Hz".
Did I miss something?
re: Hz
Take a look in include/asm/param.h:
You are both correct. When ta
You are both correct. When talking about the #define in the Linux source code, you should say "HZ". When talking about the system in general, you should probably say "Hz". :-)
Yeah, right
I mixed up the whole thing, variable name vs unit.
I must say sentences such as "Running At 10,000 HZ" are terribly misleading. :P
And HZ is probably not the best-suited name.
AFAICR from my science classes, the letter N is generally used for the frequency value, but then what's worse than a variable named "N"? :P
Hz timer
what does this benefits users ?
what are the advantages ?
Pros & Cons
Pro - Slightly lower latency but not really significant because the internal kernel latencies will be greater than this anyway
Cons - Signficant increase in kernel system overhead decreasing throughput.
Overall - Apart from making this dodgy piece of hardware in his laptop quieter, probably nothing for most users.
Re: Pros & Cons
While my main goal is to make my laptop quiet, I thought it might be of interest to other people (embedded?). The patch itself doesn't increase HZ, but cleans up some code that misbehaves (divide by zero, overflow, negative shifts) when HZ is increased. Most notably the bogomips computation is wrong with any HZ value for which 5000/HZ is not an integer.
Patch
I thought the patch looked alright at a quick glance. Nothing wrong with making things more general. I wouldn't say its too late for 2.6.
Has anyone tested 1 HZ?? :-)
Has anyone tested 1 HZ?? :-)
great
this would certainly be awesome.
say, one time in a second, you check for interrupts and stuff.
well, no more denial of services ;)
well, latency might be bigger than usual, but who cares.
~ibotty
One possibly useful application to high HZ
This might finally enable Bochs (the emulator) to keep proper real time!
Currently real-time handling in Bochs is atrocious. It uses a combination of timing how long emulated instructions run in an unit time and strange hacks to approximate the flow of real time, but I have found it is fidgety to set up and not precise.
I believe the root reason is that since Bochs tries to allow the virtual machine to set real-time interrupt frequency to any value a real PC can, it cannot simulate them with regular timer signals in Linux, since the emulated OS might want a higher frequency.
But if the Linux frequency can be an order of magnitude higher than what the emulated OS wants (and most OSes use much lower values than 10000 HZ), using timer signals in a straightforward way would be precise.