2012-04-02 6 views
21

¿Alguien puede explicar por qué se creó ashmem?¿Qué poderes especiales tiene ashmem?

Estoy navegando por mm/ashmem.c ahora mismo. Por lo que puedo decir, el kernel está pensando en ashmem como memoria respaldada por archivos que puede ser mapeada. Pero entonces, ¿por qué tomarse la molestia de implementar ashmem? Parece que se puede lograr la misma funcionalidad montando una RAM fs y luego usando filemap/mmap para compartir memoria.

Estoy seguro de que ashmem puede hacer cosas más sofisticadas: al mirar el código, parece tener algo que ver con fijar/desanclar páginas.

Respuesta

19

Ashmem permite a los procesos que no están relacionados por ascendencia compartir mapas de memoria por nombre, que se limpian automáticamente.

Los mmaps antiguos anónimos simples y la memoria compartida System V carecen de estos requisitos.

Los segmentos de memoria compartida del Sistema V se quedan cuando ya no se hace referencia a ellos mediante la ejecución de programas (que a veces es una característica, a veces una molestia).

Los mmaps compartidos anónimos se pueden pasar de un proceso primario a secundario, lo que es inflexible ya que a veces desea procesos no relacionados de esa manera para compartir memoria.

+3

Pero ashmem requiere compartir a través de los descriptores de archivos. Crear un archivo de respaldo y permitir que cada proceso lo mmap compartido alcanzaría el mismo objetivo, ¿no? Veo que esto es mejor que shmem, pero ¿cómo es mejor que tener un archivo de respaldo? –

+1

Es mejor porque, bueno, crear un archivo cuando lo que realmente quieres es un trozo de memoria compartida es una especie de ruta tortuosa. (Tener que usar un descriptor de archivo sigue siendo raro, pero menos hacky que tener un archivo allí. Los descriptores de archivos ya se generalizan a diferentes tipos de recursos, por ejemplo, sockets y dispositivos.) – Kaz

+0

Ese trabajo de fijación y desenredo parece permitirle implementar caché memoria en su aplicación que desaparecerá cuando se necesite memoria, de manera similar a los almacenamientos intermedios del kernel. La API le permite saber si la memoria se ha purgado (¿todavía tiene su caché o no). – Kaz

5

¿Alguien puede explicar por qué se creó ashmem?

David Turner (un habitual en Android NDK) respondió esto en Why was bionic/libc/include/sys/shm.h removed?:

... System V IPC se han eliminado de la magdalena. Consulte bionic/libc/docs/SYSV-IPC.TXT para obtener más información.

En resumen, los IPC del sistema V son defectuosos por diseño y no funcionan bien en entorno de tiempo de ejecución de Android donde matar a los procesos para dejar espacio para otros es normal y muy común. El resultado final es que cualquier código que dependa de estos IPC podría terminar llenando la tabla interna del kernel de las claves SysV IPC, algo que solo puede resolverse con seguridad al mediante un reinicio.

Queremos proporcionar un mecanismo alternativo en el futuro que no tenga con los mismos problemas. Una cosa que ofrecemos en este momento es ashmem, que fue diseñado específicamente para Android para evitar ese tipo de problema (aunque no está tan bien documentado como debería). Probablemente necesitemos algo similar para semáforos y/o colas de mensajes.