David Schultz wrote:
 
>On Sun, Oct 12, 2003, Dag-Erling Smrgrav wrote:
>
>
>>I've gotten used to the fact that there is a small discrepancy between
>>real and available memory, but I was surprised to see the following in
>>dmesg on a new P4 system:
>>
>>real memory  = 1073676288 (1023 MB)
>>avail memory = 1037799424 (989 MB) #역주 : 정확히 34M 차이를 보입니다.
>>
>>That's a full 40 MB difference...  where does that memory go?  is it
>>used for page maps or something like that?
>>
>>
>
>Unless this is related to Peter's recent machdep.c changes, the
>difference is probably just random chunks of memory that the BIOS
>decided to use.  This could include a shadow copy of the BIOS, the
>BIOS data segment, maybe a frame buffer for a cheap integrated
>video card, etc.  If you do a verbose boot, you'll get a list of
>the chunks of memory that are taken according to the BIOS.
>
>
>
(번역)
이 주제는 제 흥미를 자극하는군요. 그래서 저는 이것에 관해 약간 연구를 해봤습니다.
(제 512M 머신에서는 24M의 차이를 보이는군요)
This piqued my interest, so I studied it a bit. (My 512MB machine was
showing a 24MB difference)
 
그 메모리(차이나는)의 대부분은 vm_mem_init()에서 호출된 두개의 함수들에 의해 소비됩니다.
Most of the memory is swallowed by two functions called from vm_mem_init():
 
커널은 미리 사용가능한 메모리의 모든 page를 위한 vm_page 구조체를 할당합니다.
이 구조체의 사이즈가 72bytes입니다. (vm_page.c에 있는 vm_page_startup()을 보세요)
The kernel allocates a vm_page structure for every page of available
memory early on. These are 72 bytes in size. (see vm_page_startup() in
vm_page.c)
 
이후로, pmap code가 각각의 vm_page를 위한 pv_entry 구조체를 할당합니다.
(저는 이것이 아마도 훨씬 후에 할당될수도 있다고 생각합니다.
그러나 일단 각 페이지가 mapped 되면 적어도 이 구조체가 많이 필요하게 될 것입니다.)
이것이 각각 28bytes입니다.(pmap.c의 pmap_init()를 보십시오)
Later, the pmap code preallocates a pv_entry structure for each vm_page
(I assume it can probably allocate more later, but will need at least
this many if each page is mapped once). These are 28 bytes each. (See
pmap_init() in pmap.c)
 
커널 그 자체도 또한 real memory를 사용할 것입니다. 커널은 4MB의 메모리에 로드됩니다.
그리고 그 순간에 이후 4MB의 여유분이 소비되는 것으로 나옵니다.
저는 항상 그렇다고 확신하지는 않습니다.(PSE에 안내되어진것 때문에...)
불가사의한 Pentium 버그들에 대한 Bosko의 수정본이 제출되었기 때문에 바로
그것 때문이라고도 확신할 수 없습니다.
만약 당신이 운용중인 시스템의 "phys_avail" 배열을 관찰한다면, 당신은  커널을 위한
'hole(공간)'이 얼마나 많이 (메모리)를 차지하는지 볼 수 있습니다.
The kernel itself will come out of real memory too. The kernel is loaded
into 4MB pages, and any residue in the last 4MB page appears to be lost
at the moment.  I'm not sure if this was always the case (well, since
PSE was introduced) or if it's just an issue since Bosko's fix for the
weird Pentium bugs was committed. If you look at the "phys_avail" array
of a running system, you can see how much the "hole" for the kernel
takes up:
 
 > petere at hippo# gdb -k /usr/src/sys/i386/compile/HIPPO/kernel.debug
/dev/mem
 > GNU gdb 5.2.1 (FreeBSD)
 > [snip]
 > (kgdb) p phys_avail
 > $1 = {4096, 651264, 1048576, 4194304, 12738560, 526987264, 0, 0, 0, 0}
 > (kgdb)
 
이 배열은 부트때 발견된 물리적인 메모리의 범위를 보여줍니다. (0번째 부터 샌다고할때)
짝수 번째것은 범위의 시작위치, 홀수 번째는 끝이됩니다.
제 시스템의 경우 4194304와 12738559사이의 공간이 보입니다 :
여기에 커널이 로드되어 있습니다.
당신의 phys_avail map에 약 8MB의 Kenel을 위한 공간이 있다고 가정하고,
"avail memory" 메시지가 출력되기 전에 소모된 공간의 최소 추정치는
다음과 같이 계산될수 있습니다. :
This array shows the spans of physical memory that were found at boot
time. The even elements (counting from 0) are the start of the span,
with odd elements being the end. My box shows a hole between 4194304 and
12738559: This is where the kernel was loaded. Assuming your phys_avail
map had a similar 8MB hole for the kernel, then the minimum estimate of
the amount of space consumed before printing the "avail memory" message
can be calculated as follows:
 
Available memory in pages = 107366288 / 4096 = 253369
 
Space Lost to struct "vm_page"s:    253369 * 72      = 18242568
Space Lost to struct "pv_entry"s:   253369 * 28      =  7094332
Space Lost to kernel "hole":      12738560 - 4194304 =  8544256
                                                       --------
                                                       33881156 (역주 : 약 32.3MB)
 
그것은 당신이 본것에서 2M 차이 안쪽에 있습니다.
당신은 아마도 먼저 로드된 kld admin과 메시지 버퍼를 위해 약간의 공간을
더 소비할 수도 있습니다. ~???
that's within 2MB of what you're seeing. You can probably take out some
more space for preloaded kld admin overhead, and the message buffer, and
probably plenty more I can't think of (BIOS and WITNESS SYSINITS at
least happen between the final print out and the VM initialisation: that
probably accounts for a lot of the remainder)

요약하면 커널 이미지 자체의 메모리 적제로 소비하는 것과 커널에서 메모리 관리를 위해 할당한 구조체가 차지하는 메모리, 그리고 기타 소비된 메모리에 의해 차이가 난다는 것

위에 언급한 계산법을 적용해보면(커널 hole을 10M로 봤을때 29M에서 약 2M의 오차 범위내 들어갑니다.)

본 시스템의 결과를 위에 언급된 계산법으로 적용해본것
738131968 / 4096 = 180208
     
     180208 * 72 = 12974976
     180208 * 28 = 5045824
                        8544256  (디버그 정보가 없어 phys_avail를 볼 수 없어
                                     위대로 추정하면 kernel이미지가 약 6M이고
                                     4M 여유분을 생각하면 10M가 정확)
              --------------
                   26565056 (25.3MB / 29.3MB)

정확히 계산은 않해봤지만, 딱 보기에 명확한 리눅스에 비하면 어째든 조금은 애매함.
Memory: 1291944k/1310656k available (2080k kernel code, 17452k reserved, 869k data, 220k init, 393152k highmem)

FreeBSD가 워낙 눈에띄게 저부분을 출력하는 지라, 참 이상하다 하고 분석해 보았는데, 사실 리눅스와 크게 다를것은 없어 보입니다. 다만 리눅스와 비교했을때 소비된 메모리 정보를 표시하지 않아, 사용자로 하여금 궁금증을 유발하는 것으로 보입니다.
또한 위 정보대로라면 메모리 관리를 위해 너무 많은 메모리를 사용하는 것으로 보입니다.