From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 29 16:49:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEF2B106566B for ; Wed, 29 Aug 2012 16:49:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 767B68FC17 for ; Wed, 29 Aug 2012 16:49:12 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7TGnGHT049897; Wed, 29 Aug 2012 19:49:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q7TGn4YQ073936; Wed, 29 Aug 2012 19:49:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7TGn40v073935; Wed, 29 Aug 2012 19:49:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Aug 2012 19:49:04 +0300 From: Konstantin Belousov To: Patrick Mahan Message-ID: <20120829164904.GD33100@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WOMRmRCzG5HeB3RL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: "freebsd-hackers@freebsd.org" Subject: Re: Need some explanation on a field in struct vmtotal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:49:14 -0000 --WOMRmRCzG5HeB3RL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 29, 2012 at 09:09:17AM -0700, Patrick Mahan wrote: > All, >=20 > I'm trying to determine if this is a bug or for real. We have a customer= that pointed his > NMS at our appliance (running FBSD 9.0). These are 64-bit intel platform= s (8 core Xeons) > with 8 Gbytes of RAM and a 16 Gbyte swap. >=20 > The customer claims that the NMS shows him that these boxes have a tetrab= yte of VM, which > surprised him somewhat. These platforms are using net-snmp 5.7.1 out of = the ports tree. >=20 > I did an snmpget query on one of our boxes here in our lab and saw the fo= llowing: >=20 > comet1# snmpget -v2c -c public localhost hrMemorySize.0 > HOST-RESOURCES-MIB::hrMemorySize.0 =3D INTEGER: 8351368 KBytes >=20 >=20 > SNMP table: HOST-RESOURCES-MIB::hrStorageTable >=20 > hrStorageIndex hrStorageType hrStorageDescr hrStorageAllocationUnits h= rStorageSize hrStorageUsed hrStorageAllocationFailures >=20 > ... >=20 > 3 HOST-RESOURCES-TYPES::hrStorageVirtualMemory Virtual memory 409= 6 Bytes 269040967 268460681 0 >=20 > My understanding is that the 'hrStorageSize' is in 'hrStorageAllocationUn= its', so the total > byte size should be=20 >=20 > 4096 x 269040967 =3D 1085607800832 >=20 > Now, I have looked at the net-snmp code for retrieving this value and it = seems to be=20 > via a sysctl to vm.vmtotal. This value is the field t_vm in the vmtotal = structure > (defined in sys/sys/vmmeter.h). >=20 > Looking at the code in sys/vm/vm_meter.c I see the following: >=20 > TAILQ_FOREACH(object, &vm_object_list, object_list) { > /* > * Perform unsynchronized reads on the object to avoid > * a lock-order reversal. In this case, the lack of > * synchronization should not impair the accuracy of > * the reported statistics. > */ > if (object->type =3D=3D OBJT_DEVICE || object->type =3D= =3D OBJT_SG) { > /* > * Devices, like /dev/mem, will badly skew our to= tals. > */ > continue; > } > if (object->ref_count =3D=3D 0) { > /* > * Also skip unreferenced objects, including > * vnodes representing mounted file systems. > */ > continue; > } > total.t_vm +=3D object->size; >=20 > But I cannot find any description of what object->size is defined. The > vm_object structure is defined in vm/vm_object.h as type vm_pindex_t. >=20 > Which is an architecturally defined in /_types.h (for amd64 this > is defined as __uint64_t. >=20 > My FreeBSD internals (McKusick's book) for 5.5 doesn't seem to reference = it. >=20 > So my question is - Is the object->size in bytes? If this is so, then > total.t_vm is in bytes and net-snmp is using that value unmodified. Inst= ead > it should divide that value by 4096 and report that number instead? >=20 > Or is my understanding screwed up here? struct vm_object size is in pages. --WOMRmRCzG5HeB3RL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA+SAAACgkQC3+MBN1Mb4hsJQCdFnFbnXHzVaL2GkOqubIrjOa4 tFoAnibY8O3fMkw6CsFT+L1NbNWyuHu+ =/R7D -----END PGP SIGNATURE----- --WOMRmRCzG5HeB3RL--