Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: Measured overhead of timer interrupts | Date | Thu, 22 Jul 1999 19:32:01 +0400 (MSK DST) |
| |
Hello!
> why cannot it be fixed?
Certainly, it can be fixed.
My point is the following: /proc/net/* measures in HZ only things, which are meaningless for anyone but humans debugging kernel and reporting bugs. Applications need not them at all.
When timers will be variable, /proc/net/ will reflect new status. Even now we have problems with mapping /proc/net to reality; f.e. /proc/net shows 32bit of timer and it was reason why I lost day more to catch the stupidest alpha bug, which would be evident if bug reporter saw higher bits.
Besides that, we have several sysctl variables, measured in HZ, because sysctl interface in 2.2 did not allow to convert milliseconds to jiffies. It should be fixed, certainly.
> we do not want to export HZ, why should we? HZ has no meaning to anything > else than the kernel. If the kernel exports HZ-dependent values into > /proc, then that has to be fixed. (yes it might be painful in some cases) > HZ might even go away in future kernels - what if we start using > nonperiodic timer interrupts?
Mmm... HZ is necessary unixism measuring minimal timer resolution. If we will have timer with variable resolution, it will be revolution. What go you think, will this "future kernel" to schedule events in microsecond scale? It would be great improvement.
BTW, seems, timer resolution is standartized by POSIX, hence we will have to emulate it in any case. 8)
Alexey
- 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/
| |