Date: Tue, 5 Aug 2003 06:20:19 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/55124: [PATCH] request total incorrectly reported by vmstat(8) Message-ID: <200308051320.h75DKJhD012550@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/55124; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: David Schultz <das@freebsd.org>
Cc: freebsd-gnats-submit@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@FreeBSD.ORG>
> To: Bruce M Simpson <bms@spc.org>
> Cc: FreeBSD-gnats-submit@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308051320.h75DKJhD012550>