login
Search
A recent discussion on the lkml debated the merits of modifying the default hertz of the Linux kernel. The default hertz of the 2.4 kernel is 100 Hz, while the default hertz of the 2.6 kernel is currently 1000 Hz. In Andrew Morton [interview]'s plans for 2.6.13 [story] he lists a patch tagged with the comment, "changes default HZ to 250, make HZ Kconfigurable". As to why 250Hz was chosen, Linus explained in an email from May of 2004, "1kHz is also good in that it makes it easy to convert both to USER_HZ and to ms/ns. But maybe something like 250Hz would be better - still high enough that things like multimedia (which really wants higher frequencies in order to be able to sleep for fractional video-frames) should be happy, low enough that we use less CPU."
Andrew Morton explained that the problems with the current 2.6 default Hz are, "some machines exhibit appreciable latency in entering low power state via ACPI, and 1000Hz reduces their battery life. By about half, iirc." However, Alan Cox [interview] suggested that reducing the Hz to 250 may not be enough to solve these problems, "100Hz is good for power management/older boxes, 250Hz is too fast for some laptop APM to avoid clock slew, too fast for power saving and too slow for some multimedia weenies." As to how 1000Hz was selected in the first place, Linus Torvalds explained, "I chose 1000 originally partly as a way to make sure that people that assumed HZ was 100 would get a swift kick in the pants. That meant making a _big_ change, not a small subtle one." He added, "so 1kHz was a bit of an overkill, but it worked well enough that we never really got around to changing it."
From: Chris Wedgwood [email blocked] To: Linux Kernel Mailing List [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Fri, 8 Jul 2005 14:49:08 -0700 On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > [PATCH] i386: Selectable Frequency of the Timer Interrupt [...] > +choice > + prompt "Timer frequency" > + default HZ_250 WHAT? The previous value here i386 is 1000 --- so why is the default 250. Changing the *default* time interrupt frequency in a stable series is *really* bad idea if you ask me. Now that this has hit mainline please consider applying: --- kernel/Kconfig.hz~ 2005-06-24 22:16:35.023986593 -0700 +++ kernel/Kconfig.hz 2005-07-08 14:46:35.428917597 -0700 @@ -4,7 +4,7 @@ choice prompt "Timer frequency" - default HZ_250 + default HZ_1000 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
From: Andrew Morton [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Fri, 8 Jul 2005 14:59:53 -0700 Chris Wedgwood [email blocked] wrote: > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: ^^^^^^ It's been over two weeks and nobody has complained about anything. > > > [PATCH] i386: Selectable Frequency of the Timer Interrupt > > [...] > > > +choice > > + prompt "Timer frequency" > > + default HZ_250 > > WHAT? > > The previous value here i386 is 1000 --- so why is the default 250. Because 1000 is too high. > Now that this has hit mainline please consider applying: We might indeed do that. But if nobody continues to notice anything, we might not. We'll see.
From: Chris Wedgwood [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Fri, 8 Jul 2005 15:05:21 -0700 On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote: > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > ^^^^^^ > It's been over two weeks and nobody has complained about anything. Two weeks isn't that long IMO (I only just noticed myself). > Because 1000 is too high. How so? There have been comparatively few complaints about this since we switched quite some time ago. Strictly speaking I agree 1000 might be too high --- but we've had it for so long now, almost all over 2.5.x (I think?) and all of 2.6.x.
From: Linus Torvalds [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Fri, 8 Jul 2005 15:08:19 -0700 (PDT) On Fri, 8 Jul 2005, Andrew Morton wrote: > > > > The previous value here i386 is 1000 --- so why is the default 250. > > Because 1000 is too high. Yes. I chose 1000 originally partly as a way to make sure that people that assumed HZ was 100 would get a swift kick in the pants. That meant making a _big_ change, not a small subtle one. For example, people tend to react if "uptime" suddenly says the machine has been up for a hundred days (even if it's really only been up for ten), but if it is off by just a factor of two, it might be overlooked. So 1kHz was a bit of an overkill, but it worked well enough that we never really got around to changing it. Linus
From: Andrew Morton [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Fri, 8 Jul 2005 15:33:27 -0700 Lee Revell <rlrevell@joe-job.com> wrote: > > On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote: > > Chris Wedgwood [email blocked] wrote: > > > > > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > > ^^^^^^ > > > > It's been over two weeks and nobody has complained about anything. > > Wrong, I complained loudly about this as soon as it was posted, about > two weeks ago. You know what I mean. Nobody has yet reported adverse effects upon real applications.
From: Martin Schlemmer [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Sat, 09 Jul 2005 19:08:11 +0200 On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote: > Chris Wedgwood [email blocked] wrote: > > WHAT? > > > > The previous value here i386 is 1000 --- so why is the default 250. > > Because 1000 is too high. > What happened to 300 as default, as that is divisible by both 50 and 60 (or something like that) ? Wanted to remember somebody suggested rather using that ... Curiosity sake. Thanks, -- Martin Schlemmer
From: Lee Revell <rlrevell@joe-job.com> Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Sat, 09 Jul 2005 14:16:31 -0400 On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote: > On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote: > > Chris Wedgwood [email blocked] wrote: > > > > WHAT? > > > > > > The previous value here i386 is 1000 --- so why is the default 250. > > > > Because 1000 is too high. > > > > What happened to 300 as default, as that is divisible by both 50 and 60 > (or something like that) ? I still think you're absolutely insane to change the default in the middle of a stable kernel series. People WILL complain about it. Lee
From: Arjan van de Ven [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Sat, 09 Jul 2005 20:31:55 +0200 On Sat, 2005-07-09 at 14:16 -0400, Lee Revell wrote: > On Sat, 2005-07-09 at 19:08 +0200, Martin Schlemmer wrote: > > On Fri, 2005-07-08 at 14:59 -0700, Andrew Morton wrote: > > > Chris Wedgwood [email blocked] wrote: > > > > > > WHAT? > > > > > > > > The previous value here i386 is 1000 --- so why is the default 250. > > > > > > Because 1000 is too high. > > > > > > > What happened to 300 as default, as that is divisible by both 50 and 60 > > (or something like that) ? > > I still think you're absolutely insane to change the default in the > middle of a stable kernel series. People WILL complain about it. why? it's a config option. Some distros ship 100 already, others 1000, again others will do 250. What does it matter? (Although I still prefer 300 over 250 due to the 50/60 thing) This is not a userspace visible thing really with few exceptions, and well people can select the one they want, right?
From: Lee Revell <rlrevell@joe-job.com> Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Sat, 09 Jul 2005 14:36:02 -0400 On Sat, 2005-07-09 at 20:31 +0200, Arjan van de Ven wrote: > why? Because the minimum poll/select timeout is now 4ms rather than 1ms. An app that has a soft RT constraint somewhere in the middle that worked on 2.6.12 will break on 2.6.13. > it's a config option. Some distros ship 100 already, others 1000, again > others will do 250. What does it matter? > (Although I still prefer 300 over 250 due to the 50/60 thing) > > This is not a userspace visible thing really with few exceptions, and > well people can select the one they want, right? Then why not leave the default at 1000? Lee
From: Andrew Morton [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Sat, 9 Jul 2005 12:12:12 -0700 Lee Revell <rlrevell@joe-job.com> wrote: > > > This is not a userspace visible thing really with few exceptions, and > > well people can select the one they want, right? > > Then why not leave the default at 1000? Because some machines exhibit appreciable latency in entering low power state via ACPI, and 1000Hz reduces their battery life. By about half, iirc.
From: Alan Cox [email blocked] To: Andrew Morton [email blocked] Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt Date: Mon, 11 Jul 2005 14:18:51 +0100 On Gwe, 2005-07-08 at 22:59, Andrew Morton wrote: > Chris Wedgwood [email blocked] wrote: > > > > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote: > ^^^^^^ > > It's been over two weeks and nobody has complained about anything. Then your mail system is faulty because I did. 1000Hz is good for multmedia, 100Hz is good for power management/older boxes, 250Hz is too fast for some laptop APM to avoid clock slew, too fast for power saving and too slow for some multimedia weenies.
HZ
DragonFlyBSD recently changed it from 100Hz to 50Hz.
But I think AC is right, there is no value that is good for everyone.
Making it Kconfigurable is a very good idea.
do better than kconfig
I don't think that kconfigurability is going far enough... Distributors would have to package linux-image-686-50Hz, linux-image-686-250Hz, linux-image-686-1500Hz, etc...
Just put it in sysfs. That way a daemon can manipulate it at will like the CPU frequency works now.
tell them, thats the best idea ive heard
you should get on the kernel mailing list and tell them
He should write the patch, th
He should write the patch, then send it to the list.
If changing Hz at run-time wo
If changing Hz at run-time would cause funny things (I dunno if it would), could it be made into a boot option?
Boot option might as well be
Boot option might as well be a build option.
From a user's perspective, it
From a user's perspective, it's not the same. If it's a boot option, you don't need different kernel images to try different Hz, so finding out what works for your specific application is much less hassle. (reboot vs recompile)
From a developers point of view, it might be the same. Who knows? I guess most people who read kerneltrap don't really understand the internals. If they did, they'd be on lkml and wouldn't need to come here.
If I'm not completely mistake
If I'm not completely mistaken HZ is a compile-time constant that many parts of the kernel code and drivers use. It would require many changes and lots of testing to make it changeable at runtime.
No hot changes
You could definitely not change Hz on the fly as it is currently used in linux kernel. It is a constant that affects far too many subsystems. Getting dynamic ticks (change according to demand) working is more doable, possible, and even likely for our (medium to long-term) future.
250 Hz is oddly bad.
Please, use even numbers!!!
A class) 20 Hz.
B class) 50 Hz, 100 Hz, 200 Hz, 400 Hz.
C class) 1000 Hz, 2000 Hz, 4000 Hz.
D class) 10000 Hz, 20000 Hz, 40000 Hz.
R&D of J.C. Pizarro.
Nobody Complaining About It
Maybe people are complaining about it but they are complaining about the symptoms, and they don't know the real problem is the change in the timer frequency. Unless you know what the effects are going to be you can't say with certainty that no one is complaining about it. That might be really fooling yourselves.
I know my old laptop just doesn't work right with 2.6, and its ACPI doesn't work right. Is this problem because of this timer change? If it is, let me complain about it. I notice my 400 MHz PII laptop crashes on 2.6.
Now it stands to reason that a 4 GHz processor with fast memory interface, 1 MB of cache, and other speedups, just might benefit from changing the timer up by a factor of 10. Certainly if 100 Hz is doing well for a 200 MHz machine, then 1000 should work for a 4 GHz machine, unless some other factors involving real time come into play. If everything speeds up together for a 40 GHz machine, maybe this timer could be 10 kHz. But that would sure kill operation of the old 1 GHz machines.
There should be an option to set this based on the machine it is being installed upon.
I'd rather see dynamic ticks
It seems to me there's a better approach than frobbing Hz all the time at the Kconfig level based on what workload you intend to run today. (Who here does multimedia on a laptop but still wants decent battery life between movies? Ok, put your hands down.)
Why not make the tick rate more dynamic based on load? Hz then more closely represents a minimum granularity, not a rate. (Not *quite*, but close.) Check out this article on LWN for a summary on a recent dynamic tick patch.
IBM had something similar to this a few years back for 2.0 or 2.2--I forget which--that completely eliminated the periodic tick. I wonder why that one didn't catch on?
I second that. Dinamic ticks
I second that.
Dinamic ticks are cool.
I did something similar on smaller scale and it was quite nice: scheduler gives time it wants to run at and we set interrupt at that time. If some other interrupt occurs or scheduler was called prematurely, we reset scheduler wake-up interrupt again. So scheduler wasn't run needlessly. I did that to cover my quite slow scheduler, but still interrupting only when needed is quite nice improvement.
Thou I expect real world OSs like Linux do have more rough edges and not all things are easy to implement.
P.S. I actually would want to have more improvement in Linux on front of amount of interrupts. For now devices which can generate high interrupt load - read "all network adapters" - has no optimization for that case. I've seen not single Linux dying under load of single half-filled Gigabit Ethernet line. Rather sad fact.
high interrupt load
Linux already has support for NICs that generate high interrupt load - NAPI - it switches to a polling mode when interrupts get to a certain level. See this article from LWN, and this more recent one on tuning NAPI. NAPI has been around for a while now and has been backported to the 2.4.X (X > 20) series.
I'm just curious
I always wondered why isn't it a 2^n number. A good round number, like 256 perhaps?
Maybe because ticks are often
Maybe because ticks are often converted to time (seconds / milliseconds). So a round number in base 10 is better.
At least it's not the bad old days...
Then there's the bad-old-days 18.2Hz tick that the PC had originally. Try to get an even number of milliseconds or even seconds out of that easily.
(Where'd that come from? Max period on the PIC dividing down the NTSC-colorburst-derived 4.77MHz clock. 4.77MHz is 4/3rds NTSC colorburst, and was derived from the 4*NTSC pixel clock that stayed as an ISA bus signal for waaaaay too long. But, at least it matched up w/ the CGA pixel clock...)
Actually base 10 is convenien
Actually base 10 is convenient only for humans, for computers it makes no difference.
I think HZ value is also chosen partly by how well it happens to jibe with the available hardware timer ticks. You can't pick the length of the timeslice freely, as it must quantized to a multiple of the hardware clock tick that presumably occurs somewhere in kilohertz rate. Thus, there are some magical HZ values where the tick that you actually get is almost the same as what you specified.
Laptops & default Hz
I had to change the default Hz for my laptop (Panasonic W2) when I switched to a 2.6 kernel, because at 1000Hz, the machine would make a very annoying, high-pitched noise. At 100Hz, it emits a buzzing sound--audible but bearable. So I would be in favour of making HZ configurable, one way or another.
Feel like running an experiment?
Hmmm... that sounds like a marginal laptop in some way. Then again, most laptops have lots of little corners cut in their design. Do you get a similar buzz from Windows, or have you not tried it under Windows? I get similar sorts of buzzing from my corporate WinXP laptop. :-P
I'd be curious whether something like the dynamic tick patch, which eliminates the timer interrupt almost completely when the system's idle, would make your laptop more bearable? Feel like running an experiment? <:-)
Do you get a similar buzz fro
No, I used to be a windows addict but these days it doesn't do anything for me.
Anyway, I have a 120Mhz laptop and I haven't noticed any performance problems since moving to 2.6. 2.6 is *much* better in at least one way, keeping xmms from skipping while I'm doing other things. And APM suspend-to-ram never worked right under 2.4, but works fine in 2.6.
No, I used to be a windows a
No, I used to be a windows addict but these days it doesn't do anything for me.
Haha, that was very funny. :-D
No, there is no noise under W
No, there is no noise under Windows. I even RMA'd it twice because of this problem. They swapped the hard drive into three different laptops of the same model, and all made the same noise under Linux, but not Windows. After getting the machine back the second time, I finally figured out what was going on and changed the default HZ.
The dynamic tick patch looks interesting. I'll give it a try. Thanks!
Same problem here, same workaround.
I had the same problem with my Dell Inspiron 8200.
Was using this patch but these times will be over soon as it seems.
I do not appreciate the changing of the default value in the shipping kernel though. That's definitely not a change for a stable series imho.
What stable series?
Well, you seem to forget that we don't have a stable series anymore (excluding 2.4)... unless the short-lived 2.6.x.y trees count.
Windows probably doesn't sleep like Linux does
Hmmm... I wonder if Linux is actually popping in-to/out-of sleep mode with each interrupt, whereas WinXP might not bother. Either that, or WinXP is doing something like dynamic ticks.
The large variations in current draw would be what causes the buzz. You'd be surprised at what the current rush can look like when waking up the CPU. My WinXP has a similar whine when I run certain apps, but I think that's their event polling loop or something.
I'm tempted to try the dynamic tick patch on my desktop once I get lm_sensors working. I want to see if it makes a difference in CPU temps when I'm idle.
This is the dumbest thing i h
This is the dumbest thing i have read in months. This is going to cause extremely hard to reproduce issues. Not even to mention the gentoo ricers who think this in some way is going to buy them "performance".
I can not believe that brilliant guys as Morton and Torvalds are actually going to make this a button. It is totally and utterly retarded.
The granularity has a tangibl
The granularity has a tangible effect on the precision of software timers (which should NOT affect MPlayer, since this can use the RTC itself), and also on processing overhead. The BSDs have all been able to change their granularity at kernel config time for ages, but it's never been a knob in the mainline Linux kernel (though I've seen it injected into random patch sets, like -mm).
I'd like to see it in there, at least if it does have that large an effect on battery life (don't see why it should be half as long..)
I wonder why Alan considers u