Date: Wed, 28 Feb 2001 06:17:37 -0500 From: Peter Philipp <pjp@dega.daemonium.com> To: gnats-admin@FreeBSD.org, 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: <20010228061737.E7005@dega.daemonium.com> In-Reply-To: <200102280510.f1S5A1B20345@freefall.freebsd.org>; from gnats-admin@FreeBSD.org on Tue, Feb 27, 2001 at 09:10:01PM -0800 References: <200102280506.f1S56X199280@legolas.groupofnine.net> <200102280510.f1S5A1B20345@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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'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.
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.
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?20010228061737.E7005>