From owner-freebsd-bugs@FreeBSD.ORG Tue Aug 5 06:20:20 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8854137B401 for ; Tue, 5 Aug 2003 06:20:20 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE5343F85 for ; Tue, 5 Aug 2003 06:20:19 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h75DKJUp012552 for ; Tue, 5 Aug 2003 06:20:19 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h75DKJhD012550; Tue, 5 Aug 2003 06:20:19 -0700 (PDT) Date: Tue, 5 Aug 2003 06:20:19 -0700 (PDT) Message-Id: <200308051320.h75DKJhD012550@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Subject: Re: bin/55124: [PATCH] request total incorrectly reported by vmstat(8) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2003 13:20:20 -0000 The following reply was made to PR bin/55124; it has been noted by GNATS. From: Bruce Evans To: David Schultz 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 > To: Bruce M Simpson > 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