> > good point. Especially soft-RT-people like the choice of HZ=1000,
> > millisec-accuracy scheduling and timers. I remember someone even used
> > 10000, to get 100 usec accuracy timers. Even a low-end PC can take HZ=10k.
> > That one wraps jiffies every 4 days!
>
> There is only one problem with it: glibc doesn't know about it and returns
> the wrong value to posix conformant programs trying to get it with sysconf().
> Solution: add a readonly sysctl for HZ.
There is a problem with that approach. Since V7 times UNIX code uses
<sys/param.h> to get the _constant_ HZ. That means we'll break some code
when tackling the HZ thing. I consider that part of the API to be broken
anyway. We have for example DEC machines for hardware reasons can run
only with HZ = 64 but those have to share their code with other machines
where HZ = 100 or 1024. So we probably should just go ahead, make
<sys/param.h> define HZ to be __sysconf(_SC_CLK_TCK) and fix whatever
blows up when recompiling. Similar CLK_TCK. I just hope there is no
standard which says these should be constants.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/