lkml.org 
[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Measured overhead of timer interrupts
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.072 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site