Rejuveneciendo mi laptop: memoria RAM

Esta es la segunda parte de la serie Rejuveneciendo mi Laptop en la que narro, componente por componente, el proyecto en el cual busco darle una nueva vida a mi vieja laptop. Para la tabla de contenido, visita el primer post: Introducción: los problemas.

Memoria RAM

El software consume cada vez más memoria. Esta computadora, al ser de 64 bits, utiliza más RAM que una de 32 bits, simplemente por el ancho de los registros. Esta laptop originalmente tenía 4 GiB. Pronto comenzó a ser poca memoria para las necesidades diarias.

Por dar un ejemplo: en este momento (mayo de 2020) mi consumo es de 3.3 GiB, de los cuales 2.8 se consumen aproximadamente en sólo 5 programas: Chromium (931 MiB), Zoom (633 MiB), Thunderbird (553 MiB), Discord (373 MiB) y LibreOffice (348 MiB). El resto se usa en otros programas (Hexchat, Gedit, Gnome Terminal…) y el sistema (Debian, Linux, Xfce 4.14). Parecerá que 4 GiB son suficientes pero cuando se necesita desarrollar software, usar una máquina virtual, hacer una simulación o procesar video o audio, la premisa fácilmente se vuelve falsa.

Por ahí de 2015, no recuerdo bien, agregué otro módulo de 4 GiB para dejar la laptop con 8 GiB, su máximo posible. Esto fue un acierto total: me permitió ejecutar más programas simultáneos prácticamente sin swappear. Además, le di mayor capacidad al caché de disco1, por lo que después de leer un dato de disco, se incrementó significativamente la probabilidad de poderlo leer desde la copia en RAM en veces subsecuentes, mejorando la experiencia en general —no así los tiempos de arranque inicial—. La laptop prácticamente corre desde RAM una vez cargado todo. El módulo lo compré en eBay exactamente del mismo modelo que el original.

1Los efectos del caché de disco lo explico en la cuarta parte de Rejuveneciendo mi laptop: disco duro, parte 1.

En 2018, tratando de bisectar el kernel de Linux para diagnosticar un problema de compatibilidad con la laptop, me di cuenta de que el proceso de compilación crasheaba aleatoriamente con un error interno de compilación. Al reiniciar el proceso, el crash se daba en un punto distinto, lo cual descartaba un bug. Si fuera un bug en el programa, lo más probable es que el crash se daría en el mismo punto. Al no ocurrir así, es decir, al comportarse el compilador impredeciblemente, sospeché un problema de hardware, posiblemente de memoria RAM.

Cuando falla un bit de memoria (de cualquier tipo), no hay garantía de que el bit leído tenga el mismo valor que la última vez que fue escrito. Por ejemplo: si en cierto byte de memoria RAM está dañado el bit 5 (con valor 32) y una variable resulta almacenada en ese byte, cuando yo escriba un 14 en la variable y la vuelva a leer, me arrojará un 14 o un 46. Si originalmente yo escribí 46, al leerla podría obtener un 46 pero también un 14. Entonces el programa se vuelve impredecible.

Cuando un bit falla no se puede confiar en los valores leídos

Cuando un bit falla no se puede confiar en los valores leídos

Con el buen Memtest86+ al rescate, encontré dos regiones de RAM dañada de unos cuantos bits. Por eso la laptop funcionaba generalmente bien y sólo fallaba raramente y de manera aparentemente aleatoria.

Esto me llevó a buscar cómo deshabilitar esas regiones en Linux y, efectivamente, esto es posible usando el parámetro memmap al arrancar el kernel. Para usarlo en Debian habilité la siguiente línea en /etc/default/grub:

GRUB_CMDLINE_LINUX="memmap=0x10000\\\$0x00135560000 memmap=0x10000\\\$0x00175560000"

El símbolo de moneda en el parámetro memmap permite marcar regiones de memoria como reservada. Según la documentación (transcribo y traduzco):

memmap=nn[KMG]$ss[KMG]
	[KNL,ACPI] Marca memoria específica como reservada.
	La región de memoria a reservar es de ss a ss+nn.
	Ejemplo: Excluir memoria de 0x18690000-0x1869ffff
	  memmap=64K$0x18690000
	    o
	  memmap=0x10000$0x18690000
	Algunos bootloaders pueden necesitar un carácter de escape antes de '$',
	como Grub2, de otro modo '$' y el número que le siga
	serán comidos.

Entonces, con esta instrucción pude deshabilitar dos regiones de 64 KiB cada una.

Todas esas contradiagonales son para interpretar correctamente el símbolo de pesos al momento de su uso por parte de update-grub. En realidad durante la invocación en el kernel sólo queda el símbolo de pesos.

Más de una vez pensé en remplazar la tableta de RAM y hasta busqué modelos compatibles. Opté por no hacerlo y quedarme con la memoria deshabilitada por dos motivos:

  1. El módulo añadido de RAM actual es exactamente del mismo modelo que el primero. Esto garantiza el mejor aprovechamiento de la RAM en cuanto a velocidad. Tal vez los modelos compatibles hubieran funcionado bien pero yo no tenía suficientes conocimiento como para garantizármelo.
  2. Al tener sólo 128 KiB deshabilitados consideré que no valía la pena la inversión de tiempo en buscar más información, ni de dinero en el módulo.

Al final, reservar la memoria funcionó de maravilla: ya pude dejar trabajando la laptop sin preocuparme por que tronara el compilador. Ahora sólo quedaba preocuparme por los apagados debido a problemas de calentamiento. De esto hablaré más adelante.

Siguiente parte: la batería: un cambio simple que compliqué innecesariamente.


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *