Of course not. It was just an example of something that already happened @)
Do you take patches to fix it ? By turning it into ms or something like this
(just using the existing proc_dointvec_jiffies function is not enough because
seconds are not fine grained enough, it needs a new proc_dointvec_ms function)
> Notice that stuff like /proc is _expecially_ not soemthing that wouldn't
> get helped by the user knowing about HZ. Because /proc can be used from
> other machines. Some MIS person is _supposed_ to be able to do something
> like
>
> rsh xxx "echo 1 > /proc/sys/xxx/xxxx"
>
> without having to worry about whether "1" is in increments of .01 s or
> some other random interface.
I agree. I submitted several patches during 2.1.x timeframe to fix
various networking sysctls that exported jiffies. I just missed the
routing sysctls until code freeze ...
> > For soft RT apps it makes sense to recompile the kernel with a higher HZ,
> > and it would be nice if it wasn't required to recompile glibc too @)
>
> Andi, you normally understand things. Repeat after me:
>
> "Increasing the kernel HZ is not an excuse for changing a documented
> interface to user space. You can make the kernel clock tick at a
> gigahertz, but that doesn't mean that the user program needs or wants to
> know."
>
> How many times do I need to say this?
That wasn't my point. I fully agree that interfaces shouldn't depend on
the jiffies value. My point was that it is useful for soft realtime
applications to know about the system clock resolution, simply to get
an rough estimate about the expected error for timers, e.g. how long a setitimer
SIGALRM event may be delayed[1]. I believe that was the intention for the POSIX
_CLK_TLK addition to sysconf. Of course there are lots of other factors
that may cause timer delays, but doing a rough check first if the system
is able to support the required timer resolution is at least
not harmful. This is a very specific application where the timer resolution
is interesting, the majority of all programs shouldn't care.
This is of course no show stopper for 2.2, but because it is very easy to fix
and completely risk free it would be nice if you could consider the readonly
HZ exporting sysctl patch for 2.2.x or 2.3.x.
-Andi
[1] Assuming they did all other required stuff like locking memory, setting
realtime priority, etc.
-
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/