Need some explanation on a field in struct vmtotal

[Konstantin Belousov]

On Wed, Aug 29, 2012 at 09:09:17AM -0700, Patrick Mahan wrote:
> All,
> 
> 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 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 tetrabyte of VM, which
> surprised him somewhat.  These platforms are using net-snmp 5.7.1 out of the ports tree.
> 
> I did an snmpget query on one of our boxes here in our lab and saw the following:
> 
> comet1# snmpget -v2c -c public localhost hrMemorySize.0
> HOST-RESOURCES-MIB::hrMemorySize.0 = INTEGER: 8351368 KBytes
> 
> 
> SNMP table: HOST-RESOURCES-MIB::hrStorageTable
> 
> hrStorageIndex   hrStorageType  hrStorageDescr hrStorageAllocationUnits hrStorageSize hrStorageUsed hrStorageAllocationFailures
> 
> ...
> 
>      3  HOST-RESOURCES-TYPES::hrStorageVirtualMemory Virtual memory   4096 Bytes     269040967     268460681          0
> 
> My understanding is that the 'hrStorageSize' is in 'hrStorageAllocationUnits', so the total
> byte size should be 
> 
>     4096 x 269040967 = 1085607800832
> 
> Now, I have looked at the net-snmp code for retrieving this value and it seems to be 
> via a sysctl to vm.vmtotal.  This value is the field t_vm in the vmtotal structure
> (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 == OBJT_DEVICE || object->type == OBJT_SG) {
>                         /*
>                          * Devices, like /dev/mem, will badly skew our totals.
>                          */
>                         continue;
>                 }
>                 if (object->ref_count == 0) {
>                         /*
>                          * Also skip unreferenced objects, including
>                          * vnodes representing mounted file systems.
>                          */
>                         continue;
>                 }
>                 total.t_vm += 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 <machine>/_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.  Instead
> it should divide that value by 4096 and report that number instead?
> 
> Or is my understanding screwed up here?

struct vm_object size is in pages.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120829/9a8d1a48/attachment.pgp