22 de febrero de 2007

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.

8 comentarios:

  1. Anónimo10:43 a. m.

    Yo sigo aqui :)

    Me alegro que terminaras con Arturituriturii

    ResponderEliminar
  2. ¡Yo también sigo aquí! Por suerte te tengo metido en Google Reader... a él nunca se le olvida mirar tu blog por si hay algo nuevo.

    Un comentario sobre la ram y la flash: esto ya está pasando hace unos años en las PDAs. Tengo la sensación de que PalmOS estaba construído de este modo, sin hacer distinción entra RAM y flash (aunque no estoy seguro). Sin embargo pocketPC mantuvo la distinción, lo cual generó graves problemas (y absurdos, por cierto), como que el usuario perdiera todo (incluídos los programas) si la batería se descargaba. Con el 5.0 han mejorado algo esto, pero me temo que no han resuelto el problema. Porque si el código ejecutable está en la flash, ¿para qué copiarlo a la RAM entes de ejecutarlo? Me parece absurdo, en el fondo bastaría un puntero de programa apuntando a cierto sitio para obtener la siguiente instrucción ¿no?

    En una informática que se basa en evolucionar lo que hay, supongo que construir un SO "from scratch" es duro, y así convivimos con el absurdo.

    ResponderEliminar
  3. ¡¡Ey!! que yo también sigo aqui, como ermanitu, leyendote en Reader. Me gusta mucho tu blog (si exceptuamos lo de Arturito, que como eran unos ladrillos de aupa, no me leí ni uno, pero bueno).

    Por cierto... soy Alvaro :-) Creo que es la primera vez que te escribo.

    A ver como evoluciona esto de los discos duros flash... eso si, para ver un provecho de esta evolución tendremos que esperar a que Apple o la Comunidad Linuxera saque algo, que para mi que los de M$ no sacarán provecho de estos nuevos dispositivos hasta que tengan algo que copiar.

    ResponderEliminar
  4. Eso no es justo, Alvaro. Gracias al Arturito es que descubrí este lugar.
    Jo! Si hasta pensé que era un blog dedicado a Pérez Reverte! ;)

    ResponderEliminar
  5. Anónimo8:27 p. m.

    Apuesto a que esta tecnologia se estandariza en portatiles en menos de 2 años:

    SanDisk SSD Solid State Drive:
    http://www.sandisk.com/Oem/Default.aspx?CatID=1477

    ResponderEliminar
  6. Anónimo12:21 p. m.

    No soy experto pero ya hay un Portatil de Asus que trabaja con memoria flas, no tiene disco duro, creo.

    No haba entrado nunca pero me parece interesante lo que escribes.

    Saludos y adelante

    Jaime

    ResponderEliminar
  7. Anónimo4:53 p. m.

    Es verdad, las asus trabajan con discos de hasta 8 GB en flash.... pero siguen usando ram.
    osea todo proceso antes de ejecutar algun soft lo pasa a ram y lo corre.
    CUACK.
    pero algo es algo

    Saludos
    Soy Leo de Jujuy - Argentina

    ResponderEliminar
  8. Anónimo8:44 p. m.

    Chicos, por ahora no es un sueño "técnico" usar flash como ram, es facil de hacer pero no con el hardware actual (un PC con uno o dos bus de datos) pero un sistema con varios buses de datos puede mejorar muchisimo el tiempo de acceso a cada chip de memoria flash usandolos tanto como ram o como HDD en cuanto a la unificacion de datos eso no es del todo nesesario recordemos la separacion que IBM e INTEL impucieron en los primeros PC, no tenian HDD y todo ocurría en RAM pero nada estaba mezclado, despues de todo el mundo tiende a girar con o sin nuestro consentimiento

    saludos, Fx

    ResponderEliminar