From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 29 16:09:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 803F1106566B for ; Wed, 29 Aug 2012 16:09:33 +0000 (UTC) (envelope-from PMahan@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA8E8FC16 for ; Wed, 29 Aug 2012 16:09:33 +0000 (UTC) X-ASG-Debug-ID: 1346256563-027ef709373ba10001-P5m3U7 Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id uctGXVihxGp0FWDq for ; Wed, 29 Aug 2012 09:09:23 -0700 (PDT) X-Barracuda-Envelope-From: PMahan@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Wed, 29 Aug 2012 09:09:23 -0700 From: Patrick Mahan X-Barracuda-Apparent-Source-IP: fe80::7042:d8c2:5973:c523 To: "freebsd-hackers@freebsd.org" Date: Wed, 29 Aug 2012 09:09:17 -0700 Thread-Topic: Need some explanation on a field in struct vmtotal X-ASG-Orig-Subj: Need some explanation on a field in struct vmtotal Thread-Index: Ac2GAKQP1MGlcUS2RZ2GI8h/YfAL4w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {085B380F-FF78-4033-9DBC-26311B404EA2} x-cr-hashedpuzzle: ALwl An1p Bu7o Bzfy EgBo FMeH F5qn GZ4d GwDS G2aD Hdhs JMVc LBoA LQau LmFn Lta4; 1; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {085B380F-FF78-4033-9DBC-26311B404EA2}; cABtAGEAaABhAG4AQABhAGQAYQByAGEAbgBlAHQALgBjAG8AbQA=; Wed, 29 Aug 2012 16:09:17 GMT; TgBlAGUAZAAgAHMAbwBtAGUAIABlAHgAcABsAGEAbgBhAHQAaQBvAG4AIABvAG4AIABhACAAZgBpAGUAbABkACAAaQBuACAAcwB0AHIAdQBjAHQAIAB2AG0AdABvAHQAYQBsAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1346256563 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi Received-SPF: none (adaranet.com: pmahan@adaranet.com does not designate permitted sender hosts) X-Virus-Scanned: by bsmtpd at adaranet.com X-Barracuda-Spam-Score: 2.50 X-Barracuda-Spam-Status: No, SCORE=2.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MV0004 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.97753 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 2.50 BSF_SC0_MV0004 BODY: Custom Rule BSF_SC0_MV0004 Subject: 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:09:33 -0000 All, I'm trying to determine if this is a bug or for real. We have a customer t= hat pointed his NMS at our appliance (running FBSD 9.0). These are 64-bit intel platforms = (8 core Xeons) with 8 Gbytes of RAM and a 16 Gbyte swap. The customer claims that the NMS shows him that these boxes have a tetrabyt= e of VM, which surprised him somewhat. These platforms are using net-snmp 5.7.1 out of th= e ports tree. I did an snmpget query on one of our boxes here in our lab and saw the foll= owing: comet1# snmpget -v2c -c public localhost hrMemorySize.0 HOST-RESOURCES-MIB::hrMemorySize.0 =3D INTEGER: 8351368 KBytes SNMP table: HOST-RESOURCES-MIB::hrStorageTable hrStorageIndex hrStorageType hrStorageDescr hrStorageAllocationUnits hrS= torageSize hrStorageUsed hrStorageAllocationFailures ... 3 HOST-RESOURCES-TYPES::hrStorageVirtualMemory Virtual memory 4096 = Bytes 269040967 268460681 0 My understanding is that the 'hrStorageSize' is in 'hrStorageAllocationUnit= s', so the total byte size should be=20 4096 x 269040967 =3D 1085607800832 Now, I have looked at the net-snmp code for retrieving this value and it se= ems to be=20 via a sysctl to vm.vmtotal. This value is the field t_vm in the vmtotal st= ructure (defined in sys/sys/vmmeter.h). Looking at the code in sys/vm/vm_meter.c I see the following: 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 tota= ls. */ 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; 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. Which is an architecturally defined in /_types.h (for amd64 this is defined as __uint64_t. My FreeBSD internals (McKusick's book) for 5.5 doesn't seem to reference it= . 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. Instea= d it should divide that value by 4096 and report that number instead? Or is my understanding screwed up here? Thanks, Patrick ---------------------------------------------------- Patrick Mahan Lead Technical Kernel Engineer Adara Networks Disclaimer: The opinions expressed here are solely the responsibility of th= e author and are not to be construed as an official opinion of Adara Networks.