bin/55124: [PATCH] request total incorrectly reported by vmstat(8)

[Bruce Evans]

The following reply was made to PR bin/55124; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: David Schultz <das at freebsd.org>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: bin/55124: [PATCH] request total incorrectly reported by vmstat(8)
Date: Tue, 5 Aug 2003 23:17:33 +1000 (EST)

 [Resending after bounce]
 
 On Mon, 4 Aug 2003, David Schultz wrote:
 
 > The following reply was made to PR bin/55124; it has been noted by GNATS.
 >
 > From: David Schultz <das at FreeBSD.ORG>
 > To: Bruce M Simpson <bms at spc.org>
 > Cc: FreeBSD-gnats-submit at FreeBSD.ORG
 > Subject: Re: bin/55124: [PATCH] request total incorrectly reported by vmstat(8)
 > Date: Mon, 4 Aug 2003 23:23:23 -0700
 >
 >  > 	Under RELENG_4, the running total of requests for each subsystem
 >  > 	client of the vm (vmstat -m) is incorrectly reported due to the use
 >  > 	of a signed (vs unsigned) integer.
 >  [...]
 >  > -	long totuse = 0, totfree = 0, totreq = 0;
 >  > +	long totuse = 0, totfree = 0;
 >  > +	unsigned long totreq = 0;
 >
 >  This only buys you a factor of 2, then it overflows again.  totreq
 >  should be a uint64_t like the ks_calls values it's accumulating.
 
 Actually it should be (signed) int64_t like the ks_calls values it's
 accumulating.  The types of the ks_* counters have only rotted to
 unsigned types in -current (malloc.h rev.1.59).  Unsigned types should
 rarely be used since they rarely have the correct semantics.  E.g.,
 for counters, the correct handling of overflow is rarely to wrap, so
 unsigned types are only correct for counters if the factor of 2 is
 just enough.  Signed types give undefined behaviour on overflow, so
 they make automatic detection of overflows possible in principle.
 
 I just noticed that gcc implemented machine-independent trapping on
 overflow of signed addition, subtraction and multiplication about 3
 years ago (-ftrapv).  Its implementation is still primitive.  It uses
 library calls which have an overhed of about 400% for addition of
 variables in registers on an AthlonXP.  Inline i386 code ("into"
 instruction) has an overhead of between 0% and 30% in simple tests
 (depending on how well the "into" gets pipelined?).  -O2 turns off
 (breaks?) -ftrapv.
 
 Bruce