Need some explanation on a field in struct vmtotal
Patrick Mahan
PMahan at adaranet.com
Wed Aug 29 16:09:33 UTC 2012
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?
Thanks,
Patrick
----------------------------------------------------
Patrick Mahan
Lead Technical Kernel Engineer
Adara Networks
Disclaimer: The opinions expressed here are solely the responsibility of the author and are not to be
construed as an official opinion of Adara Networks.
More information about the freebsd-hackers
mailing list