Daniele Gordini wrote:
> David Luyer wrote:
> > I wrote:
> > > someone on IRC was very sad about the uptime of his machine wrapping from
> > > 497 days to 0. This patch enables the proc-filesystem to report uptimes
> > > of over 100 years. It's straight forward and only modifies get_uptime()
> > > in fs/proc/array.c.
>
> > It would be good if we could keep wrap counters for all kernel stats, however
> > updating the wrap counter on stat reporting may not be the best option. The
> > context switch count may wrap in a year where nobody looks at /proc/stat!
> > Also, the cost of the check for carry on every single context switch,
> > interrupt, etc, is possibly excessive too, making that not an attractive
> > option either.
I think, it makes no sense to extend all stat-counters to >32 bit.
For most stats the their absolute value is uninteresting. Normally,
you look at their change in the last second or so (irqs/sec, context
switches/sec, bytes/sec).
The uptime is special in two cases. First, _only_ its absolute value
is relevant and second, the interface to userland is already capable
of handling larger values because it reports float values. If you
extend the other counters to more then 32 bits, all userland utilities
have to be modified.
To keep the overflow counters correct, no kernel support is required.
Just put "0 0 31 12 * cat /proc/uptime >/dev/null" in root's crontab.
But, if you don't look at your uptime in 497 days, you don't seem to
be interested in it anyway :-)
> There is a gcc extension to support 64 bit integers as a native type
> even on 32 bit machines: try to declare a variable as "long long".
A: I don't like long longs.
B: On 64-bit CPUs a long long is 128 bit. That would be overkill.
At the moment, the overflow code is never executed on alpha.
C: long long counters makes everything slower. Now, only the query
for the value is some clock ticks slower. And see above...
Hey, I made this patch so that nobody can say "Linux can't have an
uptime of more the 497 days", not to motivate someone to overhaul
the complete system. *g*
Ciao, ET.
-
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.altern.org/andrebalsa/doc/lkml-faq.html