Robert Love provides details at KernelTrap on a recent patch he’s backported from the 2.5 development kernel to the 2.4 stable kernel. The patch allows one to adjust the frequency of the timer interrupt, defined in 2.4 with “HZ=100”. Robert 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.“
Robert Love Explains Variable HZ
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
this kind of work just shows how mature the Linux Kernel realy is….now there is plenty of time to mess around and find out ways of improoving performence rather than having to code a bunch of features that should be standrad in a kernel…this also gives them time to experiment withnew kernel level features….exciting times ahead my friends.
I think the real issue is figuring out how to start the next task sooner. In the example in the article, there needs to be a way to task switch after 81ms, not 90ms. If the thread is sitting around blocking for i/o, do a context switch.
GEOS uses 60 hz, and even on my 16mhz 186 based OmniGo 120 everything is perfectly responsive. Linux shouldn’t need a Pentium operating with 1000 context switches per second just to make things feel responsive. The key is as soon as a thread blocks, GEOS jumps back to the scheduler and finds something else to run.
I think this feature is good as “experimental”. But I really doubt that it will improve much of the responsiveness. The timers based on HZ are what I would call “slow timers” compared to anything at the diver level. So improving something that is supposed to be slow (and used as such) is not as efficient as improving the fast things.
This makes me suspect something I have suspected for a while, that there are default settings in the kernel that is based upon old assumptions. These either need to be set to more modern values, or be adaptive according to whatever it depends on (network speed for packages, CPU speed for timers, etc).
It is nice that people start fixing these things, but it would be even nicer with a linux kernel project that went through all the code to fix all of it.
I used to grouse about the fact that IBM stuck us with that silly 18.2-Hz timer, when my Atari 800 had a 60-HZ (actually, 59.9545 Hz) timer I could play with. I was excited when Linus put in a 100-Hz timer, and this is even better!
Musical work is time-critical, and the finer the Kernel’s granularity, the better…..
Earlier this year I wrote a kernel driver for the sound device on the Sega Dreamcast (see http://sourceforge.net/projects/linuxdc ) which has a real problem – at high smaple rates the driver has to spend a lot of time spinning as it cannot afford to sleep for a whole 10ms. Users are complaining but so far there is no obvious solution. This could do the trick.
I think the real issue is figuring out how to start the next task sooner. In the example in the article, there needs to be a way to task switch after 81ms, not 90ms. If the thread is sitting around blocking for i/o, do a context switch.
When a task blocks on I/O, it is unscheduled immediately and the scheduler is invoked to pick a new task. Of course the OS does not sit around for a full timer tick before reacting! The example where HZ matters is only when timeslice runs out. Timeslice management is done via the timer interrupt, and thus the system will not know if it has reached zero until the next timer interrupt which means there is a worst-case scheduling latency of HZ. This is not the end of the world, just not ideal for certain applications.
Ok… things don’t quite make sense to me here. Why would a time slice be scheduled to be a non-integer multiple of the timer interval? That really doesn’t make sense.
I still think there’s something else that’s wrong instead of this.
Ok… things don’t quite make sense to me here. Why would a time slice be scheduled to be a non-integer multiple of the timer interval? That really doesn’t make sense.
Its not, the timeslice is usually an integer of HZ. But a task can be rescheduled NOT on a timer boundary (off another interrupt returning, off another task exiting kernel space, a task slept, etc.). So then it runs out of timeslice also not on a timer boundary.