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/
