Messages in this thread | | | Date | Thu, 22 Jul 1999 20:02:59 +0200 | From | Artur Skawina <> | Subject | Re: Measured overhead of timer interrupts |
| |
kuznet@ms2.inr.ac.ru wrote: > > 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.
they do. eg. tcp timer and state data is very useful information, see other msg for an example why. no, going through netstat is not a solution. (esp considering that currently this wouldn't solve the problem anyway)
> > 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.
FWIW I don't like the overhead that a higher HZ gives, but would like to have them for other reasons (realtime, interactive stuff), so the next step would be to have a variable, adaptive HZ. That means that timer values will no longer have a granularity of one. (yes, it may not be trivial, there are time/timers/scheduling related issues)
- 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/
| |