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/