PIT, HZ, and devices

[<cwright@softpixel.com>]

Hi!

I've been working on the programmable interrupt controller (x86, maybe mips) 
and have been making a rough device outline, as i think it would be nice to 
have dynamic HZ (allows the kernel to be quick and responsive, or less 
responsive but a bit more efficient).  in the event of coding up a simple proof 
of concept, i noticed that many drivers (ftape, ide, setup, etc) also deal with 
setting/modifying the pit.  this gets messy when the pit is readonly (as i 
believe it is.  reading only returns current count, not the divisor value to 
rederive HZ).  i am considering changing the code to access a kernel-common 
system to access the clock, rather than have the current model where all code 
messes with the clock itself (most of which just reads a timestamp or resets to 
100hz mode).

is it completely a waste of time to try to make this all work, or is it maybe 
something to consider?  i imagine it would make the kernel a bit more dynamic, 
but it's also a pretty small thing to be dealing with.

I understand the placebo that floows cranking HZ up to something fast, and I am 
not after that.  I am writing some applications that could make use of having 
more interrupts for less latency.  a limited set of functionality, not worth 
hardcoding HZ to 1000 for, but realyl helpful when it's necessary.

thanks =)
christopher p wright



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/