On Jun 28, 2012, at 10:46 AM, Steve Rikli wrote: > On Thu, Jun 28, 2012 at 09:58:13AM -0400, John Baldwin wrote: >> On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote: >>> >>> I am a bit confused with all these variables defined in >>> freebsd(especially in freebsd 6.1): Which one of this represents the >>> real memory of a system? Say we bought a system with 4G ram, which one >>> tells me the RAM is 4G? >>> >>> Accordign to source code: >>> Maxmem ==> the highest page of phisycal address page : if I understand >>> correctly, this is the highest page number of physical memory that is >>> usable? >>> >>> realMem --> somehow get assigned by realmem = Maxmem: this is confuing, if >>> they are the same, why bother a realmem variables >> >> I think realMem is legacy. >> >>> physmem --> the number of usage pages : this seems the right one extract >>> the memory info, however, it seems system allocate portion of memory to >>> messge buffer which makes this physmem < 4G (assume RAM is 4G) >> >> Correct. Note that the firmware can also take up part of RAM as well (e.g. >> to hold ACPI tables). > > Given that, are the values for real & avail memory from 'dmesg' presented > anywhere like sysctl? E.g. one of my small servers has these from dmesg: > > real memory = 1073741824 (1024 MB) > avail memory = 1023852544 (976 MB) > > but the presumably equivalent sysctl values are different: > > hw.realmem: 1065287680 > hw.physmem: 1047953408 > > For system hardware inventory purposes (I assume OP is asking for reasons > along those lines, as am I) I'd want the value which reflects 1024MB of > RAM in this case, understanding that it may not be precisely the amount > available for system/user/etc. usage. > > Is dmesg the (only?) place to get that number? > > Cheers, > sr.
Here I use hw.physmem and round up to the nearest 1GB. You can also check the output of 'dmidecode -t 17' and total up the listed size of each DIMM. It gets its info from the BIOS, which probed the SPD on each EEPROM at boot time. dmidecode is in ports/sysutils/dmidecode. Sometimes a flaky motherboard won't find all of the memory, so it's useful to make sure they match. -Andrew -------------------------------------------------- Andrew Boyer abo...@averesystems.com _______________________________________________ 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"
