Re: Quick MALLOC_DEBUG patch
On 29 August 2012 20:07, Warner Losh wrote: > http://people.freebsd.org/~imp/MALLOC_DEBUG.diff > > This makes WITH/WITHOUT_MALLOC_DEBUG work. The non-standard > PRODUCTION_MALLOC form is retained for compatibility. This also needs to be > documented. > > Comments? Please! adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Quick MALLOC_DEBUG patch
http://people.freebsd.org/~imp/MALLOC_DEBUG.diff This makes WITH/WITHOUT_MALLOC_DEBUG work. The non-standard PRODUCTION_MALLOC form is retained for compatibility. This also needs to be documented. Comments? Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Need some explanation on a field in struct vmtotal
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 /_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. pgpXQF8YKQRZX.pgp Description: PGP signature
Need some explanation on a field in struct vmtotal
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 /_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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Question on io monitoring tools such as gstat and iostat
On 8/29/12 12:07 PM, Daniel Braniss wrote: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --enigCDF012FCB4FC78B4732FDA45 >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> On 8/28/12 3:14 PM, Andy Young wrote: >>> I am relatively new to using IO monitoring tools and wanted to confirm = >> I >>> understand them correctly. If I specify an interval of 5 seconds, my >>> assumption is that the data displayed is an average over that 5 second >>> interval. Is that correct or am I misunderstanding how intervals work? >>> =20 >> >> Yes, you are right. For more information you can read devstat(3) or >> sources in src/lib/libdevstat/devstat.c. > > netstat does not! > And you are right, but the question was about gstat(8) and iostat(8). They print units per second, unlike netstat(1), it prints only units without "per". -- Andrey Zonov signature.asc Description: OpenPGP digital signature
Re: Question on io monitoring tools such as gstat and iostat
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --enigCDF012FCB4FC78B4732FDA45 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > On 8/28/12 3:14 PM, Andy Young wrote: > > I am relatively new to using IO monitoring tools and wanted to confirm = > I > > understand them correctly. If I specify an interval of 5 seconds, my > > assumption is that the data displayed is an average over that 5 second > > interval. Is that correct or am I misunderstanding how intervals work? > >=20 > > Yes, you are right. For more information you can read devstat(3) or > sources in src/lib/libdevstat/devstat.c. netstat does not! danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"