Re: vmstat's entries type

Michal Mertl <mime_at_traveller.cz> wrote:
 > Even a simple increment may not be fully safe (it is also, in the end,
 > read-modify-write operation, which can be, in theory at least,
 > interrupted in between any two operations). I have not studied enough
 > of it, but it makes sense to me and I believe these were among the
 > reasons why 64 bit counters on 32 bit I386 were rejected at the time.
 > 
 > The modifications of the counters may be wrapped into preprocessor
 > macros though. The right implementation of the macro can be 100%
 > correct, but it will add big overhead - e.g. lock instrunction prefix
 > (needed in I386 SMP) takes possibly hundreds of cycles to execute).

Yes.  I've had a look at the IPFW and PF code (both have
64bit counetrs for packets and bytes).  They use mtx_lock
for locking -- not just for the counter access, but for
large parts of their packet-processing code.

 > Therefore, I think that we should either go with per-CPU copies of the
 > counter in whatever size appropriate and have the total be sum of the
 > values (possibly also taking care of overflow)

Sounds fine.

 > or we should just accept
 > the status quo - use something "natural" for the architecture (e.g. int
 > or long) and hope for the best (a wrong counter normally doesn't cause
 > any problems).

Well, it causes PRs once in a while, because people notice
the wrong values.  It can make debugging more difficult.
It makes the counters pretty much useless, because you
can't trust their values ...  You could just as well
remove the counters completely, especially those that
are incremented quickly and overflow soon.

 > It (int or sometimes long) has been good enough for decades.

"Has been good enough for decades" doesn't mean that it is
still good enough.  You have to take into account that the
data width of the i386 architecture (i.e. 32bit) hasn't
changed in the past 20 years, while the computing power,
throughput of memory and disks, bandwidth of networking
etc. have increased by several orders of magnitude.  That
means that statistics counters are incremented much faster,
overflowing a 32 bit value in shorter time.  So the problem
becomes more and more serious.

Of course, one possible way to "solve" the problem is to
just sit there and wait until 64bit architectures are main-
stream, and i386 almost non-existent.  But how long will
that take?  I think even in 10 years from now, 32bit CPUs
will still play an important role, for example in embedded
environments, for small / mobile applications etc.  You
don't need 64bit for everything.  (Even today, some 16bit
processors are in use for special purposes.  They don't run
BSD, though.)

I have just recently bought a new laptop with 32bit CPU,
and I don't intend to replace it anytime soon (my previous
laptop was in use for 5 years).  The root server that I
rented privately has a 32bit processor.  All workstations
and the office server at the company I work at are 32bit.
Most servers of our customers are 32bit.  Even many of
those that _are_ 64bit run only a 32bit OS (for various
reasons).

Oh by the way, do you think that even 64bit counters are
sufficient for the foreseeable future?  For example, a
64bit counter for 10GB-Ethernet can overflow in 58 years,
which sounds sufficient ...  But keep in mind that 10GB
will not be the end of the road.  Maybe in 5 years, some
fat boxes at large ISPs will do 1 Tbit/s.  Then the 64bit
counter can overflow in 7 months.  A 32bit counter will
last only 0.004 seconds in that case.  :-)

Just my 2 cents.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

PI:
int f[9814],b,c=9814,g,i;long a=1e4,d,e,h;
main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a)
while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;}