> Especially as the only thing that knows about HZ is "clock_t", and if I
> remember correctly the _only_ system call that actually returns a clock_t
> is "clock()".
There is a sys_times(), which can become sys_oldtimes() if needed.
There are far worse problems in /proc. Jiffies are directly reported
all over /proc.
The real question is whether or not any of the places which report times
in clock ticks --- clock(), times(), and the various places in /proc ---
are places where we would want additional accuracy after we bump HZ to
some higher value. If not, we can simply change the kernel HZ to be
1024 (for example), and then for the clock() and times() system calls,
scale the return values by 100/1024 so that they have the correct value
if HZ were 100. We could do the same thing for all of the places where
jiffies are returned in /proc.
It certainly would be possible to arrange things so that the kernel
internally uses a fast HZ, but none of the userland interfaces see a
difference, because all of the places that report "jiffies" are scaled
so that they are correct for a value of 100 for HZ.
- Ted
-
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/