El Kernel de Linux - Memory Manager

Memory Manager

El Memory Manager o administrador de memoria permite lo siguiente:

• Gran espacio de direcciones : Los programas pueden requerir más memoria que la que físicamente existe
• Protección : La memoria asignada un proceso es privada para tal.
• Mapas de Memoria : Se puede mapear un archivo dentro de un area de memoria virtual y acceder al archivo como si fuera memoria
• Acceso Limpio a la Memoria Física : el MM asegura que los procesos puedan usar transparentemente todos los recursos de la máquina, asegurando además un rendimiento aceptable
• Memoria Compartida : Permite que los procesos puedan compartir trozos de la memoria asignada.

El Administrador de memoria posee dos interfaces : una interfaz con llamada a sistema que es usada por los procesos de usuario (User Space) y una interface que es usada por los otros subsistemas (Kernel Space).

Algunas de las llamadas de usuario incluyen malloc() y free(). Las llamadas de kernel incluyen kmalloc() y kfree().

Ya que Linux soporta multiples arquitecturas, es necesario entonces que existan rutinas específicas para abstraer los detalles del uso del hardware en una sola interface.

El Memory Manager usa el administrador de memoria de hardware para mapear direcciones virtuales a direcciones físicas. Gracias a esto, los procesos no están concientes de cuanta memoria física está asociada a una dirección virtual. Esto permite al MM poder mover trozos de memoria virtual dentro de la memoria física. Además, permite que dos procesos puedan compartir dos trozos de memoria física si las regiones de memoria virtual asignadas a ellas son mapeadas en la misma dirección física.

Otro concepto importante es el Swapping o intercambio, que es intercambiar (swap) memoria ocupada por procesos en un archivo. Esto le permite al kernel poder ejecutar mayor cantidad de procesos que usen mayor cantidad de memoria física existente. El MM posee un demonio, kswapd, para ejecutar la tarea de intercambiar zonas de memoria en archivos y viceversa. Este demonio chequea periodicamente si no existen direcciones físicas mapeadas recientemente. Estas direcciones son vaciadas de la memoria física, y además de ésto, el MM minimiza la cantidad de actividad de disco necesaria para hacer este intercambio.

El administrador de memoria del hardware detecta cuando un proceso de usuario tiene acceso a una porcion de memoria no mapeada en una dirección virtual y avisa al kernel de esta falla. Existen dos alternativas para solucionar esto:

• o la pagina de memoria es volcada a un archivo y viceversa
• o el proceso está haciendo referencia a una zona de memoria no permitida

Si el administrador de memoria detecta un acceso no permitido (a la memoria) notifica al proceso con una señal. Si el proceso no sabe como manejar esta señal, el proceso es finalizado. 8. Virtual File System

Linux está diseñado para soportar distintos típos de dispositivos físicos. Incluso para un tipo específico, como un disco duro, existen diferentes interfaces de manejo entre un fabricante de hardware y otro. Además de los dispositivos físicos, Linux posee soporte para sistemas de archivos lógicos que lo hace interoperante entre distintos sistemas operativos, con los siguientes propósitos:

• Multiples dispositivos físicos de hardware
• Multiples sistemas de archivos lógicos
• Múltiples tipos de archivos ejecutables
• Homogeneidad, es decir, una interfaz común entre los sistemas de archivos lógicos y el hardware
• Rendimiento
• Seguridad de datos, perder o corromper datos
• Seguridad de acceso, restricción a los archivos, quotas, permisos, etc.

También se usan dos interfaces para el manejo de filesystems. Una interfaz para llamadas de usuarios y otra para los subsistemas del kernel. La interfaz para los usuarios maneja archivos y directorios. Las operaciones en archivos incluyen open/read/close/write/seek, que están definidas en el estandar POSIX y en los directorios readdir/creat/unlink/chmod/stat tambien definidas en POSIX.

Pero la interface de los subsistemas del Kernel es bastante mas interesante. Esta posee estructuras de datos y funciones para manipulación directa para otros subsistemas. De hecho, existen dos interfaces para el resto del kernel: inodos y archivos.

La interfaz de inodos posee soporte para create(), lookup(), link()/symlink(), mkdir(), mknod(),etc.

La interfaz de archivos posee soporte para open()/release(), read()/write(), select(), mmap(), fsync(), etc.

Volviendo con los controladores de dispositivos o drivers, Linux posee tres tipos de drivers: char, block y network. Los dos más relevantes son char y block. Los dispositivos char son aquellos que su lectura es secuencial (de a un char a la vez), como un mouse. Los dispositivos block pueden ser accedidos de cualquier manera, pero solo puede leerse o escribirse de a bloques.

Todos los drivers soportan las operaciones mencionadas recien. Además, cada dispositivo puede ser accesado como si fuera un archivo. Ya que el Kernel se entiende con los dispositivos de esa manera, no es complicado agregar un nuevo dispositivo, ya que solo es necesario implementar el código específico del hardware para el soporte de la abstracción de archivos.

Además, el kernel posee un buffer de caché para mejorar el rendimiento cuando usa dispositivos block. Todo acceso a un dispositivo block pasa a través de un subsistema de buffer. Este buffer aumenta considerablemente el rendimiento minimizando las lecturas y escrituras hacia y desde los dispositivos.

Cada dispositivo posee una cola de peticion (request queue). Cuando el buffer no puede responder una petición, se agrega una petición a esta cola y hace que la petición duerma (sleep) hasta que pueda responder. Este buffer usa un espacio separado del kernel como un thread unico, manejado por kflushd.

Existen distintos mecanismos para mover datos entre el computador hacia los dispositivos

• Polling (votación)
• DMA (acceso directo a memoria)
• Interrupciones

En el caso de polling, el driver verifica periódicamente el CSR (Control & Status Register) para ver si la petición ha sido completada. Si es así, el dispositivo inicia la siguiente petición y continua. Polling es altamente efectivo en dispositivos de transferencia lenta, como disketteras y modems.

En el caso de DMA, el driver inicia una transferencia directa entre la memoria del computador y el periférico. Esta transferencia es concurrente con la CPU y permite que la CPU siga haciendo otras tareas mientras se transfieren datos. Cuando la operación termina, la CPU recibe una interrupción.

Cuando un dispositivo desea cambiar de estado (por ejemplo, presionar el botón del mouse) o reporta el final de una operación, envía una interrupción al procesador. Si las interrupciones estan habilitadas, el procesador detiene su ejecución actual y comienza a ejecutar el codigo de manejo de interrupciones del kernel. El kernel encuentra el manejador correcto para invocar. Cuando una interrupción es manejada, la CPU se ejecuta en un contexto especial, es decir, todas las interrupciones quedan pendientes hasta que la interrupción actual haya terminado. Debido a esto, los manejadores de interrupciones deben ser altamente eficientes. Si ocurre el caso que un manejador de interrupciones no puede terminar el trabajo, reasigna el trabajo pendiente en un manejador de tipo “bottom-half” , es decir, codigo que se ejecutará la proxima vez que la llamada sea completada para evitar latencias y promover la concurrencia.

Volviendo ahora a los sistemas de archivos lógicos, es más fácil acceder a un dispositivo si es manejado como un archivo que directamente en el hardware. Un filesystem lógico puede ser montado en un punto de montaje dentro del filesystem virtual. Esto significa que un bloque asociado a un dispositivo contiene archivos y una información de estructura que permite al filesystem lógico acceder al dispositivo. Un dispositivo sólo puede tener un soporte lógico de archivo. Sin embargo, el dispositivo puede ser “adiestrado” para poseer soporte para un soporte lógico en otro tipo de filesystem.

En pocas palabras y con una explicación más clara, los dispositivos por lo general se encuentran en /dev y cada dispositivo se representa como un archivo. Es perfectamente posible reescribir el manejador del dispositivo para que soporte otro tipo de filesystem lógico.

Para el soporte de filesystems virtuales, Linux usa Inodos para representar un archivo en un dispositivo block. El inodo es virtual en el sentido que contiene operaciones que estan implementadas de distintas maneras, dependiendo del sistema lógico y físico donde el archivo reside. El inodo es usado como un lugar de almacenamiento para toda la información relacionada con el manejo de, por ejemplo, abrir un archivo del disco. Guarda buffers, el largo del archivo , etc.

Mucha de la funcionabilidad de los filesystems virtuales radica en los módulos. Esta configuración permite a los usuarios compilar un Kernel tan pequeño como sea posible, cargando solamente los modulos que sean necesarios.

[ N. del E.: de repente sale la incógnita, el soporte para , lo compilo como módulo o integrado al kernel? aquí esta la respuesta].

Ideal es el caso en el cual el dispositivo pudiera ocuparse y liberarse en tiempo de ejecución. Si el módulo fuera agreagado activamente al kernel, se deben pasar sus parámetros en momento de booteo, sin considerar tampoco el gasto de memoria en mantener el uso de un dispositivo que no esté conectado, como por ejemplo, una impresora.