Sobre las unidades de memoria flash y la memoria RAM

Despues de haber conseguido echar a tres de las cuatro personas que leian este blog con mi Revertavalancha, y una pausa no eneramente deliberada de varios días, continuo mi tradicional vómito de mis mal llamadas ideas.

Ya escribí en su día explicando brevemente porque creo que los dispositivos de almacenamiento de datos van a dejar de estar basados en los dispositivos mecánicos actuales de una puñetera vez - lleva décadas prediciendose - y van a basarse en memorias "flash" a medio plazo; basándo el razonamiento en la lentitud y la decreciente fiabilidad de los discos mecánicos y la ausencia de tipos de datos que nos fuerzen a necesitar con urgencia mayores tamaños de almacenamiento. Las noticias de avances de ese sector no han hecho más que confirmar mis teorías, que por otra parte no son precisamente el secreto de la eterna juventud. Habrán oido ustedes noticias de que han creado técnicas para aumentar la capacidad de los discos duros y dirán que no tengo razón en mi predicción, pero apuesto a que ninguna empresa ha inventado un sistema mágico para mejorar y poder seguír mejorando sensiblemente en el futuro la latencia de acceso aleatorio a ese supersistema de almacenamiento.

El caso es que hoy quería hacer una reflexión de una tontería que en realidad no va a pasar: La unificación de la memoria ram con los dispositivos de almacenamiento.

En los sistemas modernos, la RAM y los discos duros son entes separados, y el procesador solo puede referenciar directamente datos. Eso básicamente quiere decir que cuando el procesador hace un jmp 0x12345678, ese 0x12345678 debe estar en memoria RAM. Para que se pueda ejecutar un programa hay que copiarlo del disco duro a la RAM y, ahí ya si, ejecutarlo. ¿Por qué esto es así? Principalmente por la jerarquía de los caches, es decir, la lentitud del discos duro respecto a la RAM, L1/L2 y registros. Mover el brazo de un disco duro hace que el procesador desaproveche algunas decenas de millones de ciclos, que aunque a nivel global pueda corregirse mediante la multitarea - ejecutar otro proceso mientras se espera -, a efectos reales del usuario que espera que se arranque su programa, es el mismo: Lentitud. Crear una memoria RAM de varios gigas es factible, pero muy caro, asi que se recurre al disco duro. Cuando hay que ejecutar, leer, mapear algún dato del disco duro, se mueve a RAM y se ejecuta, se gestiona el cache, se escriben los cambios a disco. Pero como ya he dicho, el mundo de los discos duros va a acabar. Esto provocará la aparición de discos duros basados en memoria flash. ¿Por qué no ir más allá y hacer lo más "lógico": Establecer ese disco duro flash como memoria RAM?

Es bastante improbable que esto suceda. En primer lugar porque siempre será más barato construir los discos duros flash de memoria con peor velocidad de acceso que la memoria RAM, siempre; más aun teniendo en cuenta que la RAM no está obligada a conservar el estado entre reinicios. Pero si ocurriera, ¿a que retos se enfrentarían los sistemas operativos?

Los sistemas operativos están construidos bajo el concepto de que nada más arrancar, la RAM esta vacia. Esto, que puede parecer una tontería, es la madre del cordero, porque con un disco duro-RAM con persistencia de datos sería continua. A día de hoy el sistema operativo arranca, la BIOS se mapea - creo - en una parte de la RAM y el procesador comienza a ejecutar el código. Se carga el núcleo del kernel y voilá, lo primero que se hace es mirar cuanta RAM hay, construir las estructuras de datos para gestionarla (tablas de páginas y demás), y siempre se asume que esa memoria está vacia.

Con una memoria RAM basada en memoria flash persistente todo sería muy diferente. Nada más arrancar el kernel, tendría que detectar que zonas de la RAM están siendo utilizadas para datos - lo estamos utilizando como disco duro, al fin y al cabo - y que zonas hay libres. La "gestión de memoria" pasaría a ser al mismo tiempo el sistema de archivos. Habría que volver a pensar algunos conceptos básicos: La frontera entre los datos y la memoria sería inexistente. Hacer un malloc() sería idéntico a hacer un open() + write(). De hecho, teóricamente habria que unificarlo todo, eliminar malloc(). Eliminar toda la gestión de memoria anónima y sustituirlo, supongo, por las APIs de gestión de archivos. En el caso de que queramos seguir utilizando sistemas de archivos jerárquicos para la ocasión. Ńo haría falta suspender el sistema, ni apagarlo: Tan solo salvar el IP, los registros y demás en una zona fija de la memoria que el cargador pudiera encontrar al arrancar. ¿Y que me dicen de las particiones de sistemas operativos? Puesto que la frontera entre datos y memoria sería nula, no tendría sentido partir un disco flash de 40 GB en dos particiones de 20 GB: Al arrancar un sistema de 20 GB perderías los GB de memoria aun no utilizada por la otra particion (recordar que no existiría el swap ni nada parecido). Tendrían que utilizar ambos el mismo sistema de archivos, es decir, el mismo gestor de memoria. ¿Y que me dicen del procesador? En una arquitectura como las viejas de 32 bits no se podría utilizar un disco duro flash de 100 GB, porque el procesador solo podría acceder a los primeros 2^32 (4 GB), y a los procesadroes de 64 bits algún día les pasará algo parecido.

En fin, como ya he dicho es muy probable que esto no pase jamás porque es más conveniente seguir teniendo "discos duros" por separado, sean flash, mecánicos, o lo que sean. Pero es interesante comprobar como es posible dar la vuelta al mundo cambiando un par de conceptos.