Date: Wed, 28 Feb 2001 06:10:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/25445: /usr/src/usr.bin/vmstat/vmstat.c & /usr/src/sys/sys/malloc.h type differences Message-ID: <200102281410.f1SEA2L48056@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/25445; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Peter Philipp <pjp@dega.daemonium.com> Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/25445: /usr/src/usr.bin/vmstat/vmstat.c & /usr/src/sys/sys/malloc.h type differences Date: Thu, 1 Mar 2001 01:06:40 +1100 (EST) On Wed, 28 Feb 2001, Peter Philipp wrote: > Whoops I messed that up somewhat. Let's try again this time I won't write > the patches because they are erroneous (and actually go back and break > alpha while leaving i386 ok, it's a tug-of-war see :P go intel). I think you need to reply to freebsd-gnats-submit, not gnats-admin, so that the reply gets put in the database instead of in an overworked admin's mailbox. I quoted it all so that it will be in the database via this reply. > > I've also read up on the history why we are seeing this bug. Revision 1.46 > in sys/malloc.h had a member type changed from long to int64_t. As far as I > know a long for the alpha is 64 bits anyhow but a long for i386 is 32 bits. > So it didn't do anything for the alpha in fact but increased the size of > ks_calls to 64 bits for the i386. This created a type size problem for > vmstat -m where the type for printing totreq was long which is 32 bits and > not 64 bits. It creates this in a vmstat -m: > > Memory Totals: In Use Free Requests > 94474K 1759K -2126966145 > > Perhaps the total requests should be printed as a quad_t which is independent > of platform and always 64 bits it seems. I think that is sufficient. Someone should turn on -Wformat globally to inhibit new printf format errors. I hope we fixed most of the old ones. > > Anyhow this seems to open a few cans of worms (shudder) and also goes back to > size differences in structures such as struct malloc_type where on alpha > a set of stats collected as type long can hold a lot more than on i386 which > isn't fair and isn't consistent, which is unfortunately sucky. This is a fairly large problem. `long' is the wrong type for all counters, but `u_long' is not much better (it has only twice the range). At least using `long' and printing correctly it gives obviously bogus counts when counters overflows. Fixed-size types are not the correct type for counters unless the range of the counter is known. They may be too inefficient. Atomic updates of 64-bit counters are especially inefficient on i386's. > > If I'm totally wrong here, I'd love a good explaining, cuz I'll need it. > > -- > - - > Peter Philipp <pjp@daemonium.com> > Daemonium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102281410.f1SEA2L48056>