avail memory issue

I've just upgraded my hardware and performed a new install of 12.0. Upon checking /var/run/dmesg.boot, I see that the real and avail memory have a massive discrepancy.

Code:
real memory  = 8589934592 (8192 MB)
avail memory = 1907277824 (1818 MB)
Any thoughts on what this might be?

Additional information:

Motherboard is an ASRock Z170 Pro4S

Code:
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE-p3 GENERIC i386
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz (3408.12-MHz 686-class CPU)
  Origin="GenuineIntel"  Id=0x906e9  Family=0x6  Model=0x9e  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100000<NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0xc000000<IBPB,STIBP>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 1907277824 (1818 MB)
 
Any particular reason for installing the FreeBSD i386 rather than amd64? I suspect that is at least part of, if not the whole, issue.

Code:
FreeBSD 11.2-STABLE #4 r341245: Fri Nov 30 15:59:38 AEDT 2018
    root@shadow:/usr/obj/usr/src/sys/MACMINI amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU     P8700  @ 2.53GHz (2520.73-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0xc08e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1<LAHF>
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7983710208 (7613 MB)
 
Any particular reason for installing the FreeBSD i386 rather than amd64? I suspect that is at least part of, if not the whole, issue.

I'm confused as why I would install AMD64 for an Intel processor? Granted, I've not installed FreeBSD recently. Is this the only 64-bit OS? Didn't things used to be different? You'd install the right OS for the right architecture? Maybe I'm getting too old for this. :)
 
As trev suspects, it is highly likely the real and available memory discrepancy has it’s cause of the i386 platform.
From FreeBSD FAQ’s: 4.1.3 Why does FreeBSD report less than 4 GB memory when installed on an i386™ machine?

The total address space on i386™ machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). Furthermore, some addresses in this range are reserved by hardware for different purposes, for example for using and controlling PCI devices, for accessing video memory, and so on. Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration.

This FAQ might not be up to date. FreeBSD 12.0 might reserve more memory from 4 GB then in the above example.
 
Short version, AMD was the first with 64 bit instructions and registers as an extension to the original x86 32 bit instructions and registers. This was called AMD64. This proved to be so popular that Intel copied it and called it Intel 64. FreeBSD was quite quick to implement it and used the original name, AMD64, for the architecture.

Despite it's name, AMD64 is not specifically for AMD processors.
 
And, that fixed it.

Code:
FreeBSD 12.0-RELEASE r341666 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz (3408.13-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x906e9  Family=0x6  Model=0x9e  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0xc000000<IBPB,STIBP>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7918915584 (7552 MB)

Thank you all, again! :)
 
I've just upgraded my hardware and performed a new install of 12.0. Upon checking /var/run/dmesg.boot, I see that the real and avail memory have a massive discrepancy.

Code:
real memory  = 8589934592 (8192 MB)
avail memory = 1907277824 (1818 MB)
Any thoughts on what this might be?

What figures did you have before you upgraded?

My understanding is that 32-bit OSes such as the i386 version of FreeBSD cannot address 8GB of RAM - 4GB being the limit.
 
With PAE, a 32-bit kernel can access even more than 4GB, just not all at the same time. Think of it this way: Every process can get it's own 2GB of address space (just not two processes at the same time) which is backed by real memory, plus 2GB reserved for kernel and buffer cache which are common. But that introduces inefficiencies, and limitations for device drivers. This kind of technique has been used for decades.
 
Back
Top