Someone suggested to me that the "simple expedient" of redefine HZ to
something other than 100 might not work, even if I corrected the value
in the other necessary place as well, because some device drivers
hard-code things to assume that HZ is 100.
It was also pointed out that allowing for a system call that changes
HZ (and thus making HZ a variable instead of a constant) would make
Linux "bigger and slower".
How about some form of subdividing the system clock? i.e. Make the
system clock fire at some (ideally controllable through a system call)
multiple of 100 Hz, but have it pretend like it's running at 100 Hz
for many parts of the kernel, e.g. device drivers that might depend
on this.
What this boils down to is that I really really really would like
to have a 1000-Hz system clock or faster, so that I could get SIGPROF's
every millisecond or less. The faster the clock fires, the more
accurate the profiling results are, and I really don't care too much
about the fact that my program will run slower as a result.
ben
-- "... then the day came when the risk to remain tight in a bud was more painful than the risk it took to blossom." -- Anais Nin