>When I change how the page cache works, do I suddenly change the "read()"
>system call to take different parameters? No. Similarly, any user should
>not be aware of what the kernel does internally to keep its timers
>up-to-date. It's supposed to be opaque.
Hmm. You mean that the best performance anyone can ever expect from a
Linux system should be the one indicated by the user-level view of
HZ=100 ?
This is silly. Applications that use the kernel to provide a
user-level clock via setitimer() are limited by the kernel value as
is, and to say that even if the kernel value increases, they should
never, ever try to take advantage of it seems strangely un-Linux like
to me. Don't we want applications to be able to work as well as
possible ? If I have a box capable of support HZ=1000, then my user
level application can reasonably ask for an itimer of < 10ms. If the
value of HZ=100, this makes no sense, and causes erratic timing
behaviour in the application. Why is it so wrong to be able to ask
"whats the minimum value for a timer that makes sense ?", which is
effectively a function of HZ ?
--pbd
-
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/