Hasta hace una horas estaba con 2GB y la curiosidad era muy grande de los 4GB y sus problemas. Yo manejaba todo de haber leído de por ahí para tirar una ayuda a alguien y por mera curiosidad. Bueno, ahí va algunas pruebas.


En BIOS:



Configurado a mano (ya que las memos se ponen por seguridad en 5-5-5-15 y son en realidad 4-4-4-15):


Primero que nada, antes de hacer macanas: dos pasadas de memtest86+ 2.01, y cero errores.

Memtest86+
Desde no se que versión soporta PAE, con lo cual puede acceder a toda la memoria por arriba de los 4GB.
En los escaneos se ve que lo hace en tres partes: 128K - 2048M | 2048M - 3583M | 4096M - 4608M

Notar que 3583M = 4095 (memoria usable) - 512 (que es la memoria reservada por los PCI y demás chirimbolos).
Luego 4608M = 4096 + 512 (que es la memoria remapeada por encima de los 4GB)

Quiere decir que mi rango de mapa de memoria va a ir de 0GB a 4.5GB. Si le agrego otra placa de video es muy probable que remapee 1G y no 0.5G, con lo cual mi rango se expande de 0GB a 5GB.


Linux version 2.6.24.7 (original)



¿Como es mi mapa de memoria que me dice el BIOS?. Esto es totalmente independiente de si es 32 bits, 64 bits o lo que sea el sistema operativo.



Haciendo un "zoom"


Ahí se puede ver que lo usable son los famosos "640k" de ¿se acuerdan DOS?
Luego se ve unos 3.5GB usables, el groso groso, y finalmente unos 0.5GB.

Bien, a esos 0.5GB hay dos formas de acceder en 32 bits con PAE, o en 64 bits, que PAE es un requerimiento de los 64 bits, sino sólo voy a ver 3.5GB de RAM.

El gran tema es que hay ciertas configuraciones viejas que ese remapeo no lo hace, por lo que lo ocupado por el PCI se pierde, no importa que sistema operativo ponga.

Bien, antes dije que en mi vieja configuración disponía de 2GB, y con lo cual, para tener esos 2GB disponibles, tenía en principio dos alternativas:

* Usar una separación de memoria común usuario/kernel de 3G/1G + HIGHMEM, lo que da unos 896MB de LOWMEM + 128MB VMALLOC + 1024MB HIGHMEM para el resto, y en consecuencia teniendo cierta pérdida no sólo por esos 128MB para usar de "trampolin" entre la memoria baja y alta, sino que una perdida de performance para acceder a la memoria alta.

* Usar una separación sin HIGHMEM: de 2G/2G (pequeña perdida de 128MB) o 2G/2G_OPT (que en realidad es 2.125/1.875 para ser exacto) para ver completo estos 2GB como LOWMEM sin uso de HIGHMEM y por consiguiente sin perdida en rendimiento, eso sí, ninguna aplicación podía superar los 2GB, cosa que en mi caso nunca pasó.
Existen otras contras de usar un split distinto de 3G/1G, por ejemplo el Wine no funciona, y puede que ciertos drivers binarios cerrados no funcionen tampoco, no es es caso de NVIDIA.





¿Que pasa al arrancar un kernel de 32 bits con 2G/2G_OPT (sin HIGHMEM) y 4GB (bueno en realidad 4.5GB por el remapeo que se hace)
(este fue mi arranque inicial)



Me da un aviso particular, me dice, que sólo voy a ver 2G , y pero que si quiero ver toda la RAM habilite HIGHMEM64G.
Dice HIGHMEM64G, y no, el HIGHMEM4G porque hay memoria por arriba de los 4GB, y para acceder a la misma es necesario PAE.

Al fin y al cabo la memoria que dispongo es:





Compilo mi kernel cambiando a 3G/1G sin HIGHMEM (sólo por diversión)
Arranco:



Y sólo ve otro número famoso que es 896MB de RAM (1024MB - 128MB de VMALLOC)





De aquí en más sigo con el split standard de memoria de 3G/1G.

Bien, avancemos un poco habilito HIGHMEM4G.







Pero yo quiero mis 4GB!

OK, habilito PAE. (HIGHMEM64G)







Sí, no son 4096MB, desde ya que no, el kernel ocupa espacio junto con otras estructuras internas que se detallan ahí, tampoco en 1G tenes 1G ni en 2G tenes 2G, etc.


Fijense la diferencia importante del segundo número de estas razones 2075060k/2097152k | 905524k/917504k | 3630456k/4194304k | 4150620k/4718592k.



Otro split típico es del de 3G/1G_OPT que es en realidad 2.75/1.25 para tener FULL 1GB de RAM en máquinas con 1GB de RAM. Existe uno de 1G/3G, pero realmente es muy chico. Ves unos 3GB-128MB de RAM, pero tus apps no pueden superar 1GB.

La regla es: "lo que yo le asigno al kernel en la separación de memoria es lo que voy a tener de LOWMEM, lo demás será visible sólo si habilito HIGHMEM"


OK, pasemos a 64 bits

errores de acceso a dispositivos, PCI (sata, usb, etc etc etc).... y.....
KERNEL PANIC no encuentra el /

Bien, yo tenía ajustadito el kernel, entonces no tenía habilitado el IOMMU (GART de AMD)
¿Que es masomenos el IOMMU? Bueno, permite acceder utilizando un método especial a los dispositivos PCI que son de 32 bits cuando se está en 64 bits.
AMD tiene un IOMMU simulado con un AGP GART, Intel no dispone de tal circuito y la solución es usa un área de memoria RAM de "bounce buffer" (conocido como "double buffer" en entornos Windows) para de ahí hacer las transferencias.

¿Ambas soluciones se comen memoria? Sí.

¿Que hago? arranco el kernel con mem=4G o mem=3G (lo mismo da, mientras sea 32 bits máximo) con esto el kernel arranca perfecto.

Recompilo el kernel con IOMMU GART AMD.

Bien, ahora juego...

Parametros del kernel mem=4G iommu=off




Notar la diferencia con lo anterior en cuanto a la "visibilidad" debido al mem=4G y que en 64 bits no existe el concepto de memoria LOW y HIGH


Ahora sí, sí o sí IOMMU si quiero esos 0.5GB extras, de lo contrario KERNEL PANIC, no es posible una comunicación con el PCI.

Bien, sin parámetros:



Mi placa no tiene AGP, por lo que no tengo una forma de configurar una apertura de memoria, el kernel dice, 32MB que hay actualmente son muy chicos, lo subo a 64MB y los pongo en la dirección 8000000.



Bien, se puede leer por varios lados, errores FEOS pero muy FEOS y con corrupción de datos, al llenarse esta memoria de IOMMU, por lo que se recomienda para solventar el problema agrandarla. El error del que hablo es "PCI-DMA: Out of IOMMU space for XXXXXX bytes at device NNNN:NN:NN.N"

Por lo visto se da en transferencias altas de datos.

La solución es agrandar este espacio default de 64MB por soft en caso de que el BIOS no lo permita, ¿como? con un parámetro del kernel ( Documentation/x86_64/boot-options.txt )



(La regla es 32 << N , 00010000 desplazamiento a izquiera N lugares )

Bueno, arranco con 256MB de apertura, por las dudas (128 lo salteo)






Resumiendo un poco lo que sirve: ¡memoria usable por mis aplicaciones!



(*) Gano 507MB, realmente no se que tanto rendimiento pierdo por un nivel más en direccionamiento por PAE, supongo que actualmente es despreciable, 64 bits siempre PAE y no nos quejamos...)
(**) Uso 64 bits 3.5GB de RAM y me quedo tranquilo de que no va a ver temas de corrupción de datos al no usar el IOMMU (si este se desborda)
(***) 64 bits, 3.9GB casi 4GB) pero.... corro el riesgo de corrupción de datos
(****) 64 bits, 3.7GB casi +256MB que (**) pero uso un IOMMU, que SUPONGO YO, con 256MB no hay problema de corrupción de datos.

Y para terminar, creo, me parece, digo... En un sistema con 4GB, y que si el GART, como leí por ahí, puede dar quilombos (no lo se si con 256MB ocurre), creo que vale la pena sacrificar 256MB menos y no usar el IOMMU.

Ahora la cosa cambia claro, cuando mi sistema dispone de más de 4GB, ahí, sí o sí tengo que usar IOMMU y es cuestión de probar si con 256MB de GART no hay problema.

Tema importante, no se si existe en "desktop", tengo que informarme mejor. El PCI soporta un modo que es DAC (Dual Address Cycle) esto permite en 64 bits, partir la dirección de 64 bits en dos, enviando en un ciclo una parte de 32 bits y en el otro la que resta.



Espero que sea de ayuda y aclaración.

Cualquier duda, sugerencia, experimento (que no ponga en riesgo mis datos) será bienvenido.

Son las 2:45 de la matina ¡ME VOY A DORMIR!

¡Buena salud y buen sexo!

PD: Ahora sí, acabé con la curiosidad, una especie de nirvana

despues lo leo de nuevo, es la primera vez que me mareo leyendo.
JAJAJAJA
dormi 4 horas nomas, despues le pego una revisada linea por linea a ver que onda.
se ve muy completo, gracias por tomarte el trabajo de recompilar tus observaciones y compartirlas.

pasará lo mismo en sparc, ppc, arm, etc?

Ufff, la proxiam consulat al oculista me la pagas vos,eh?

Solo en CPU X86 ~ X86-64

http://en.wikipedia.org/wiki/Physical_Address_Extension
http://www.intel.com/support/processors/sb/CS-001617.htm

Este tema me tiene podrido en el laburo llaman todo el tiempo,
**porque si tengo 4GB de memoria el guindos me dice que tengo menos?**

Lejos quedaron los tiempos donde el problema era los timmings o ranks para la memoria de servidores....

pensé que habías captado la indirecta...

me parece que gera se quiere levantar a alguien de aca

con mem=4G y iommu=noaperture se evita el mensaje de aviso, ya que directamente no busca una apertura. En tema de memoria es lo mismo, ya que al darle antes iommu=off la apertura no se usa.

Esto es aplicable en caso de tener un IOMMU configurado @ kernel. (me animo a decir que por defecto en todo kernel de distribución de 64 bits)

---------------------

Estuve chusmeando un poco el código de lo relacionado con el acceso DMA a los PCI con IOMMU/SWIOTLB y da miedito.

Se leen cosas como:

(en la parte del mensaje de error de sin espacio)
PCI-DMA: Out of IOMMU space for %lu bytes at device %s

arch/x86/kernel/pci-gart_64.c

y lo mismo para swiotlb (caso intel o amd en caso de usar iommu=soft)


DMA: Out of SW-IOMMU space for %zu bytes at device %s

lib/swiotlb.c

.config 2.6.24.7 @ 32 bits http://pastebin.com/f52e37654
.config 2.6.24.7 @ 64 bits http://pastebin.com/f16bd7cae

dmesg @ 32 http://pastebin.com/f400b41ba
dmesg @ 64 http://pastebin.com/f1c6a36f3 (mem=4G iommu=noaperture)
dmesg @ 64 http://pastebin.com/f6bb60cba (iommu=memaper=3)

ia32 no da para mas

+1.

Pero hace rato que no da para más. Es un parche tras parche. Además cada uno implementa los chips como se le da la gana y es un terrible quilombo, pero así y todo funciona y dudo que valla a cambiar. Vamos a estar en el 2020 y todavía va a ser compatible los procesadores "del común" con 8086.

Podrían decir, bueno muchachos... Esto no da para más... Hagamos una arquitectura que tire para unos buenos años, con buenas características, extensible, escalable. El tema es el software actual y todo el movimiento de la migrada loca. Que se yo...

Igual creo que lo actual sirve al mercado, digo: hoy agrego esto, que permite esto, mañana agrego aquello otro, y así... $$$.

bueno.

el tema tambien con otros tipos de procesadores (ppc, sparc, etc) es que el que lo inventó es el unico que lo fabrica, es decir, mas alla de que ia32 sea una mierda como arquitectura como diria Theo de raadt en este excelente thread (http://kerneltrap.org/OpenBSD/Virtualization_Security ).

Tambien hay que tener en cuenta que es mas o menos la misma diferencia que hay entre un software en el cual hay una sola rama y el mismo software con 85000 forks, y cada uno haciendo las cosas como quiere o como le conviene y los otros grupos cada X tiempo mergeando los cambios de los otros contra su propio trunk.
Eventualmente algo va a salir mal.

Confirmado, con 256MB no hay problema, o al menos para la carga de este señor.