2010-01-28 8 views
5

El siguiente es el resultado después de ejecutar en solaris, muestra que hay dos montones, pero en mi entender, para un proceso, hay solo un montón que es una gran memoria continua que puede ser administrado por brk para expandir o reducir el tamaño. Y para la memoria anónima, un proceso puede tener muchas memorias anónimas que pueden ser administradas por mmap/munmap. Es mi entendimiento correcto? o leí el resultado del pmap erróneamente?montón VS anon memory en el resultado de pmap

sol9 # pmap -sx pgrep testprog

... 00022000 3960 3960 3960 - 8K rwx-- [pila]

00400000 131072 131072 131072 - 4M rwx-- [pila]

... FF390000 8 8 - - 8K libc_psr.so.1 rx--

FF3B0000 8 8 8 - 8K rwx-- [anon]

...


total de Kb 135968 135944 135112 -

Respuesta

2

Los dos son correctas y leer mal la salida pmap. Si hubiera hecho pmap -x los resultados probablemente serían menos confusos, mostrando el montón solo una vez, pero desde que agregó el indicador -s, divide el montón en segmentos con diferentes asignaciones de página.

Las direcciones que comienzan en 0x0022000 no están alineadas correctamente para ser asignadas a una página de 4Mb, entonces usan 3960kb de páginas de 8k. 0x0022000 + (3960 * 1024) = 0x00400000

En 0x00400000 la dirección está alineada correctamente para las páginas de 4Mb, por lo que el montón pasa a utilizar las páginas más grandes con menos entradas de la tabla de páginas.

Si desea asegurarse de que su montón comenzó en la alineación correcta para usar páginas de 4Mb para todo, en lugar de comenzar con 8k hasta que alcanzara un límite de alineación, vincularía su programa con -M /usr/lib/ld/map.bssalign para hacerlo.

Se puede encontrar una explicación un poco más detallada en el Page Size and Memory Layout blog post del Solaris Application Programming autor Darryl Gove.

Cuestiones relacionadas