[snip]
> 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.
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".
The only drawback is that not all the operations are open-coded, it
depends on the architecture. For example, on the i386 architecture the
division operation is done by means of an external routine, which is
not available in the standard kernel.
Anyway that routine (and similar ones for the architectures that
need them) are available in one of the libraries that come with gcc
(libgcc2.a if I remember correctly) and IMHO their inclusion would
be neither difficult nor expensive.
I think that using this feature to migrate the counters from 32 to
64 bits would be worth considering for the next source revision
(maybe 2.3.x ?). This is certainly cleaner than wrap-counters
(at least in my opinion) and breaks nothing since if the accounting
worked before it will continue to work after: the operations are the
same, only data size changes. Maybe problems could arise if one of
these counter needs an atomic update, but I bet those cases are well
known and easy to deal with (if they exist altogether)
Of course this would mean that gcc (and derivatives) would be the
only compiler allowed to compile the kernel. However I strongly suspect
that this is true even now, but I am not a kernel guru, so I won't
assure I'm right here.
[snip]
>
> David.
>
-
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