It's probably not a *big* deal now (in 2.2) but it's definately something
that can and should be addressed in the future. As things get faster,
2^32 isn't so large anymore. This is happening faster than 32-bit is
dying.
I think using 64-bit counters on i386 is unreasonable. These counters
are often incremented in extremely performance-critical areas. Using
a polled system where the kernel remembers when 32-bit counters overflowed
might be workable.
A quick (untested, uncompiled, and horribly naive WRT cache-line interactions)
exaple:
#if sizeof(unsigned long)<8
typedef struct _longcounter {
unsigned long counter;
unsigned long lastobserved;
unsigned long rollovers;
struct _longcounter *next; } longcounter;
#define LONGCOUNTER_INITIALIZER { 0,0,0,0 }
#define add_longcounter(C,V) do { (C.counter)+=(V) } while(0);
#define value_longcounter(C) (({ unsigned long j; \
if( j > cnt->counter ) cnt->rollover++; \
cnt->lastobserved = j; }),
((unsigned long long) C.rollover)<<32|C.counter)
void testrollover(longcounter *cnt) { /* Call periodically from somewhere */
unsigned long j;
while(cnt) {
j = cnt->lastobserved;
if( j > cnt->counter ) cnt->rollovers++;
cnt->lastobserved = j;
cnt = cnt->next; } }
#else
/* Native implementation for 64-bit archs */
typedef unsigned long longcounter;
#define LONGCOUNTER_INITIALIZER 0
#define add_longcoutner(C,V) do { (C)+=(V) } while(0);
#define value_longcounter(C) (C)
#define testrollover(C) 0
#endif
/* Not shown -
* - method for registering longcounters so they appear in the proper
* linked list
* - method of printing the unsigned long long as a decimal number
* - perhaps we other need a macro to report the difference in two
* longcounters as an unsigned long?
* - where to call testrollover()? Perhaps there could be multiple
* chains of counters... most could get checked every 10 minutes or
* so, while the ones requiring high-frequency checks could go
* every minute... or maybe some or all should just check their own
* rollover in a driver or subsystem specific way...
*/
> (and now that I think
> about it they will break some monitoring software.)
No it wouldn't. The data comes out of /proc in decimal format - values
under 2^32 will look exactly the same.
Right now both the kernel and likely most monitoring software is broken
wrt 32-bit rollover. If we fix the kernel, the monitoring software will
be no more or less broken.
> > Theoretically, it takes only 344 seconds to push over 4 GB stuff
> > out to 100 Mb/s ethernet.
Practically, it takes only about a minute to push out 4GB over HIPPI.
I agree this is a relatively minor issue, but it *would* be nice to be
able to check on a machine that's been up for a hundred days and get
an accurate picture of how much network bandwidth its used.
-Mitch
-
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