Resizable BAR / SAM: el pequeño interruptor que puede mejorar mucho

enero 16, 2026 • febrero 3, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Introduces una GPU nueva en una flota de estaciones de trabajo, ejecutas benchmarks y… nada. O peor: unas pocas máquinas se aceleran, otras sufren extraños
tirones, y una decide arrancar solo los martes. El título del ticket dice «regresión de rendimiento gráfico», pero la causa raíz es un ajuste de BIOS que la mayoría
trata como adorno.

Resizable BAR (y el nombre comercial de AMD, Smart Access Memory / SAM) es precisamente ese tipo de ajuste: pequeño, fácil de configurar mal y capaz
de mover cargas reales. También es una excelente manera de descubrir cuántas capas hay entre «la aplicación quiere una textura» y «los bytes llegan a la GPU».

Qué cambia realmente Resizable BAR/SAM

Los dispositivos PCI Express exponen regiones mapeadas en memoria llamadas BAR: Base Address Registers. Son el modo en que la CPU (y el SO) mapea los registros
de un dispositivo y, a veces, fragmentos de la memoria del dispositivo dentro del espacio de direcciones del sistema. Históricamente, las GPU solo exponían una pequeña
«ventana» de su VRAM hacia la CPU en un momento dado—comúnmente 256 MB—por lo que la CPU solo podía mapear y acceder directamente a una porción de la VRAM. Si la CPU necesitaba
tocar otra parte de la VRAM, la ventana tenía que volver a mapearse.

Resizable BAR es una capacidad de PCIe que permite al firmware del sistema/SO negociar un tamaño de BAR mayor para el dispositivo—posibilitando mapear mucha más
VRAM de la GPU en el espacio de direcciones de la CPU al mismo tiempo. Eso puede reducir la sobrecarga de remapeo y mejorar el rendimiento en cargas que implican
cargas impulsadas por la CPU, transmisión de assets y muchas transferencias pequeñas. A veces no hace nada. A veces importa.

Smart Access Memory (SAM) de AMD no es una tecnología diferente; es el empaquetado de Resizable BAR por parte de AMD + validación de plataforma + una casilla en el BIOS
que te hace sentir que desbloqueaste algo. En NVIDIA sigue siendo Resizable BAR, típicamente habilitado mediante BIOS más perfiles de controlador/juego.

Aquí tienes el modelo mental práctico: Resizable BAR no hace la GPU más rápida. Cambia cuán eficazmente la CPU puede direccionar y alimentar la memoria de la GPU.
Si tu cuello de botella son los shaders, los núcleos de ray tracing o la GPU ya está saturando su propio ancho de banda de memoria, el tamaño de la BAR no te salvará.
Si tu cuello de botella es «la CPU hace muchas pequeñas interacciones con VRAM mientras transmite», el tamaño de la BAR puede mover la aguja.

La explicación menos comercial: tamaño de ventana y remapeos

Sin Resizable BAR, la CPU ve una pequeña ventana de la VRAM. Imagina un almacén con una ranura de correo: puedes pasar cajas, pero una a la vez y vas cambiando
a qué estantería apunta la ranura. Resizable BAR agranda la abertura, a veces lo suficiente para ver todo el almacén. La sobrecarga de manipulación disminuye.
Si eso se traduce en FPS depende de si la «sobrecarga de manipulación» era realmente tu factor limitante.

Una cita, porque la gente de operaciones necesita columna vertebral

La esperanza no es una estrategia. — Ed Catmull (atribuido en círculos de ingeniería)

Hechos y contexto: por qué existe

No obtienes un interruptor de BIOS así sin una larga cadena de compromisos. Aquí hay hechos concretos y migas históricas que vale la pena conocer
antes de empezar a cambiar interruptores en producción.

Los BAR existen desde antes de las GPUs modernas. Los BAR forman parte de la especificación PCI de la era en que «memoria de dispositivo» solía significar ventanas de registros y buffers pequeños, no 24 GB de VRAM.
256 MB se convirtió en una apertura de GPU de facto. Durante años, muchas plataformas mapearon una BAR prefetechable de 256 MB para GPUs, que «estaba bien» cuando los tamaños de VRAM y los patrones de tráfico CPU↔GPU eran diferentes.
Resizable BAR es una capacidad de PCIe, no una invención del vendedor. El mecanismo existe en PCIe, pero la habilitación masiva para consumidores llegó tarde porque firmware, SO y drivers debían comportarse correctamente.
“Above 4G Decoding” trata del espacio de direcciones, no del rendimiento. Permite al firmware asignar espacio MMIO de PCIe por encima del límite de 4 GB, esencial cuando las BAR grandes chocan con ventanas MMIO de 32 bits limitadas.
UEFI importa porque la canalización de arranque asigna recursos. Las rutas de arranque Legacy/CSM y expectativas de option ROM antiguas a menudo hacen que las asignaciones MMIO grandes y flexibles sean dolorosas o imposibles.
Las placas para servidores se preocuparon antes que las de gamer. Plataformas de alto nivel que rutinariamente mapean enormes regiones MMIO (HBAs, NICs con SR-IOV, aceleradores) empujaron el ecosistema hacia políticas de asignación más sensatas.
Los drivers limitan el comportamiento agresivamente. NVIDIA históricamente habilitó Resizable BAR por juego/perfil porque «funciona en papel» no es lo mismo que «funciona en 500 motores con 500 peculiaridades.»
La virtualización lo complica. Passthrough, grupos IOMMU y asignaciones de firmware dentro de VMs pueden impedir mapas de BAR grandes incluso si el host los soporta.
No es solo para juegos. Algunas tuberías de creación de contenido y cómputo se benefician cuando la preparación desde CPU y la gestión de memoria de la GPU interactúan intensamente.

Cuándo ayuda (y cuándo no)

Dónde tiende a ayudar Resizable BAR

Cargas con transmisión intensiva de assets: juegos de mundo abierto, escenas grandes, transmisión frecuente de texturas/geométricas.
Envío de renderización limitado por CPU con muchas transferencias: la CPU pasa tiempo coordinando cargas y transiciones de recursos.
Algunas aplicaciones de creación: cronologías de proyectos grandes, texturas de alta resolución, conmutaciones frecuentes de caché—dependiendo de la arquitectura de la app.
Benchmarks que imitan transmisión real: no solo «carga máxima de shaders», sino «cargar/expulsar/cargar de nuevo».

Dónde usualmente no ayuda

Escenarios puramente limitados por GPU (alta resolución + sombreado intenso) donde la GPU ya es el factor limitante.
Cargas dominadas por el ancho de banda local de la memoria de la GPU más que por transacciones CPU↔GPU.
Engines o aplicaciones muy viejas que no estresan el comportamiento de mapeo de VRAM de la CPU.
Sistemas limitados por la disposición de carriles PCIe (x8 vs x16, enlaces de chipset) o por I/O de almacenamiento que alimenta assets.

Chequeo de realidad: es una perilla, no un milagro

Resizable BAR puede producir mejoras significativas en algunos títulos y flujos de trabajo, pero no es un botón garantizado de «rendimiento gratis». La razón por la que se volvió un ciclo de hype es simple: es uno de los pocos cambios a nivel de plataforma que pueden mostrar ganancias medibles sin comprar una GPU nueva. Eso no lo hace beneficioso universalmente; lo hace tentador.

Broma #1: Resizable BAR es como darle a tu GPU una pajita más grande—genial si estabas limitado por la pajita, inútil si estabas limitado por la bebida.

Requisitos estrictos y trampas de compatibilidad

En entornos de producción—sí, incluso «rigs de juego en producción» en laboratorios corporativos—quieres un comportamiento determinista. Resizable BAR tiene prerequisitos.
Si alguno no se cumple, obtendrás habilitación parcial, ninguna habilitación o habilitación con efectos secundarios extraños.

Requisitos de plataforma (los sospechosos habituales)

Arranque UEFI (CSM desactivado en la mayoría de los casos).
Above 4G Decoding habilitado en BIOS/UEFI.
Resizable BAR habilitado en BIOS/UEFI.
Soporte del VBIOS de la GPU para Resizable BAR.
Firmware de placa que asigne MMIO de forma sensata (aquí es donde «último BIOS» deja de ser opcional).
Soporte de SO + driver (Windows y kernels Linux modernos lo soportan generalmente, pero los drivers pueden seguir limitando su uso).

Trampas que deberías buscar activamente

Entornos GPU mixtos: iGPU habilitado + dGPU + dispositivos PCIe adicionales pueden empujar la asignación MMIO a casos límite.
Muchos dispositivos PCIe: NICs, HBAs, tarjetas NVMe AIC, tarjetas de captura—el espacio MMIO se llena.
Virtualización/passthrough: el invitado puede no poder mapear BAR grandes, o el hipervisor podría limitarlas.
Option ROMs antiguas: las expectativas legacy del ROM pueden entrar en conflicto con mapeos de BAR grandes.
Interfaz «habilitado» sospechosa: algunos firmwares muestran el interruptor pero no asignan realmente una BAR mayor.

Guía rápida de diagnóstico (primero/segundo/tercero)

Si estás depurando una queja de rendimiento y alguien menciona Resizable BAR, necesitas responder tres preguntas rápido:
(1) ¿está realmente habilitado?, (2) ¿es la carga sensible a ello?, y (3) ¿es otra cosa el cuello de botella?

Primero: verifica que esté habilitado de extremo a extremo

Revisa los ajustes de BIOS: Above 4G Decoding, Resizable BAR, CSM/arranque Legacy.
En el SO, confirma que el tamaño de la BAR de la GPU sea mayor que la ventana legacy (a menudo > 256M).
Confirma que el driver lo reconoce (NVIDIA Control Panel en Windows; sysfs/lspci en Linux).

Segundo: confirma que mides el cuello de botella correcto

Utilización de GPU, utilización de VRAM, utilización de CPU por núcleo.
Consistencia del tiempo de cuadro (tirones vs FPS promedio).
Ancho/velocidad del enlace PCIe (x16 Gen4 vs x8 Gen3 pueden dominar el resultado).

Tercero: busca conflictos de asignación de recursos

dmesg/registro de eventos de Windows para advertencias de asignación de recursos PCI.
Quirks de IOMMU/ACS si hay passthrough involucrado.
Otros dispositivos consumiendo espacio MMIO (múltiples NVMe AICs, NICs con SR-IOV).

Si no puedes probar que está habilitado, deja de discutir sobre benchmarks. Si puedes probar que está habilitado pero nada cambia, asume que no estás limitado por la BAR.
Sigue adelante.

Tareas prácticas con comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando alguien dice «Resizable BAR está activado» o «SAM rompió mi máquina». Cada tarea incluye un comando realista,
salida de ejemplo, lo que significa y la decisión que impulsa. Los comandos se centran en Linux porque Linux expone la verdad sin dramatismo de interfaz.
Puedes adaptar la lógica a herramientas de Windows si trabajas allí.

Tarea 1: Identificar la dirección PCI de la GPU

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)

Significado: La GPU está en 01:00.0. Usarás esa dirección para todas las inspecciones PCIe más profundas.
Decisión: Enfócate en el dispositivo correcto; no adivines cuando existen múltiples GPUs.

Tarea 2: Comprobar tamaños de BAR y si parecen «grandes»

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "Region 0|Region 2|prefetchable"
Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Region 2: Memory at 4000000000 (64-bit, prefetchable) [size=16G]

Significado: Una BAR prefetechable de 16G es un indicador fuerte de que Resizable BAR está activo y mapeando una gran apertura de VRAM.
El comportamiento legacy suele ser ~256M. Tus números exactos pueden variar.
Decisión: Si aún ves solo una pequeña región prefetechable, vuelve a los prerrequisitos de firmware/modo de arranque.

Tarea 3: Confirmar que existe la capacidad Resizable BAR

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -n "Resizable BAR" -A6
214:	Capabilities: [bb0] Resizable BAR
215:		Resizable BAR: BAR 2: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB

Significado: El dispositivo anuncia la capacidad Resizable BAR y negoció un mapeo de 16GB.
Decisión: Si la capacidad está ausente, probablemente necesites una actualización del VBIOS de la GPU o la GPU simplemente no la soporte.

Tarea 4: Comprobar rápidamente el modo de arranque (UEFI vs legacy)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Significado: Estás arrancando vía UEFI.
Decisión: Si obtienes «Legacy», desactiva CSM/arranque Legacy y reinstala o convierte el arranque; de lo contrario, la habilitación de BAR grande suele fallar.

Tarea 5: Confirmar que el kernel vio asignaciones tipo “Above 4G” sin errores

cr0x@server:~$ dmesg -T | grep -iE "pci.*resource|BAR|mmio" | tail -n 8
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: BAR 2: assigned [mem 0x4000000000-0x43ffffffff 64bit pref]
[Mon Jan 20 09:41:05 2026] pci 0000:00:01.0: PCI bridge to [bus 01]
[Mon Jan 20 09:41:05 2026] pci_bus 0000:01: resource 0 [mem 0x4000000000-0x43ffffffff 64bit pref]

Significado: El kernel asignó con éxito una gran ventana prefetechable de 64 bits.
Decisión: Si ves «not enough MMIO resources» o fallos de asignación de BAR, espera inestabilidad o retroceso de la BAR.

Tarea 6: Validar ancho y velocidad del enlace PCIe (el asesino silencioso)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
LnkCap:	Port #0, Speed 16GT/s, Width x16, ASPM L0s L1
LnkSta:	Speed 16GT/s (ok), Width x16 (ok)

Significado: Estás funcionando al equivalente Gen4 x16 (16GT/s) y con todo el ancho. Bien.
Decisión: Si esto muestra x8 o Gen3, arregla el asiento, elección de ranura, bifurcación de carriles en BIOS, risers o el ruteo del chipset antes de culpar a la BAR.

Tarea 7: Comprobar el estado de IOMMU (relevante para passthrough y algunas plataformas)

cr0x@server:~$ dmesg -T | grep -iE "IOMMU|DMAR|AMD-Vi" | head
[Mon Jan 20 09:41:03 2026] AMD-Vi: IOMMU performance counters supported
[Mon Jan 20 09:41:03 2026] AMD-Vi: IOMMU enabled

Significado: IOMMU está habilitado. Bueno para aislamiento, a veces malo para rutas sensibles a la latencia si está mal configurado.
Decisión: Si haces passthrough de GPU y la BAR grande no persiste, puede que necesites ajustes en el hipervisor que permitan MMIO grande.

Tarea 8: Inspeccionar el mapeo de recursos en sysfs para la GPU

cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/resource
0x00000000f6000000 0x00000000f6ffffff 0x0000000000040200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000004000000000 0x00000043ffffffff 0x000000000004220c

Significado: La tercera línea muestra una región mapeada enorme (0x4000… a 0x43ff…), consistente con una BAR grande.
Decisión: Si la región prefetechable es pequeña o falta, tu habilitación no es real.

Tarea 9: Confirmar que el driver cargó y qué GPU está activa

cr0x@server:~$ lsmod | grep -E "^nvidia|^amdgpu" | head
nvidia_drm             86016  3
nvidia_modeset       1241088  7 nvidia_drm
nvidia              62738432  340 nvidia_modeset

Significado: Los módulos kernel de NVIDIA están cargados.
Decisión: Si estás en el driver equivocado (nouveau vs nvidia, o una pila amdgpu desajustada), el comportamiento de la BAR y el rendimiento serán impredecibles.

Tarea 10: Comprobar tamaño de VRAM y estadísticas básicas en runtime (sanidad)

cr0x@server:~$ nvidia-smi --query-gpu=name,pci.bus_id,memory.total,pcie.link.gen.current,pcie.link.width.current --format=csv
name, pci.bus_id, memory.total [MiB], pcie.link.gen.current, pcie.link.width.current
NVIDIA GeForce RTX 3090, 00000000:01:00.0, 24576 MiB, 4, 16

Significado: Confirma que estás consultando la GPU correcta y que el enlace PCIe está sano.
Decisión: Si el gen/width del enlace es bajo bajo carga, revisa administración de energía o ajustes BIOS de «PCIe speed».

Tarea 11: Medir comportamiento ligado a CPU vs GPU durante una ejecución (rápido y sucio)

cr0x@server:~$ sudo apt-get -y install sysstat >/dev/null
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 	01/21/2026 	_x86_64_	(32 CPU)

09:52:10 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:52:11 AM  all   32.1  0.0  6.2   0.4    0.0  0.7    0.0    0.0    0.0   60.6
09:52:11 AM   7    97.0  0.0  2.0   0.0    0.0  0.0    0.0    0.0    0.0    1.0

Significado: Un núcleo está al máximo. Eso huele a cuello de botella en envío por CPU o una porción monohilo de la carga.
Decisión: Si uno o dos núcleos están saturados mientras la GPU tiene baja utilización, Resizable BAR podría ayudar algo—pero también deberías perseguir causas en el lado CPU.

Tarea 12: Verificar que el almacenamiento no sea el verdadero cuello de botella de «streaming»

cr0x@server:~$ iostat -xm 1 3
Linux 6.5.0 (server) 	01/21/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.10    0.00    5.92    6.33    0.00   59.65

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await  aqu-sz  %util
nvme0n1         820.0  94200.0     0.0    0.00    7.10   114.88    12.0    980.0   2.10    5.90   94.0

Significado: El dispositivo NVMe está al ~94% de utilización con un await no trivial. La transmisión de assets podría estar limitada por almacenamiento.
Decisión: Si el almacenamiento está saturado, los cambios de BAR no arreglarán los tirones; arregla I/O (almacenamiento más rápido, mejor caché, menos contención) primero.

Tarea 13: Comprobar hugepages/THP y presión básica de memoria (el stutter puede ser por memoria)

cr0x@server:~$ grep -E "MemTotal|MemAvailable|SwapTotal|SwapFree" /proc/meminfo
MemTotal:       131840512 kB
MemAvailable:    18422528 kB
SwapTotal:      16777212 kB
SwapFree:        1024000 kB

Significado: Tienes poca memoria disponible y el swap está mayormente usado. Eso puede causar picos de tiempo de cuadro desagradables no relacionados con la BAR.
Decisión: Si existe presión de memoria, arréglala antes de atribuir mejoras/regresiones a la BAR.

Tarea 14: Enumerar otros dispositivos PCIe que compiten por espacio MMIO

cr0x@server:~$ lspci | grep -E "Ethernet|Non-Volatile memory|SATA|RAID|Fibre|Infiniband"
03:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)

Significado: Varios dispositivos pueden requerir ventanas MMIO; con una BAR grande, la asignación puede apretarse.
Decisión: Si la habilitación de BAR falla en sistemas «completos» pero funciona en mínimos, considera reducir dispositivos, cambiar ranuras o actualizar firmware.

Tarea 15: Comprobar si el kernel recortó tamaños de BAR (común con quirks)

cr0x@server:~$ dmesg -T | grep -iE "Resizable BAR|resizable|clamp|re-size|rebar" | tail -n 20
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: enabling Extended Tags
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: BAR 2: resized to 16GB

Significado: El kernel redimensionó explícitamente la BAR.
Decisión: Si ves líneas de «failed to resize», no estás obteniendo la característica aunque la BIOS diga «Enabled».

Tarea 16: (Virtualización) Comprobar readiness de BAR grande en host para QEMU/KVM

cr0x@server:~$ sudo dmesg -T | grep -i vfio | tail -n 8
[Mon Jan 20 10:03:12 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Mon Jan 20 10:03:12 2026] vfio-pci 0000:01:00.0: BAR 2: can't reserve [mem 0x4000000000-0x43ffffffff 64bit pref]

Significado: VFIO no puede reservar esa gran ventana de BAR para passthrough con la configuración actual.
Decisión: Necesitas ajustar configuraciones del hipervisor/firmware de VM (p. ej., permitir MMIO grande, OVMF, espacio de direcciones del invitado) o aceptar que no habrá BAR grande en el invitado.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Un equipo de medios desplegó nuevas estaciones de trabajo para editores. Mismo modelo de GPU que en el piloto. Mismo paquete de drivers. Misma imagen de SO. La única diferencia fue la
revisión de la placa madre—intercambiada discretamente por compras porque «equivalente».

Las máquinas piloto mostraron mejoras en el scrubbing de la línea de tiempo y en la consistencia de la vista previa tras habilitar Resizable BAR. Así que la guía de despliegue decía:
«Habilitar ReBAR + Above 4G, validar con un benchmark, enviar». Esa guía asumía que «Habilitado en BIOS» significaba «Habilitado en realidad».

En una semana, los tickets de soporte se acumularon: pantallas negras intermitentes, cierres aleatorios de aplicaciones durante exportes y un par de máquinas que empezaron
a congelarse bajo carga. El benchmark usado para la validación no desencadenó el problema; la carga real de edición sí.

La causa raíz no fue mística. En las placas «equivalentes», el firmware asignaba recursos PCIe de forma distinta cuando se instalaron múltiples unidades NVMe y una NIC de 10GbE.
Con la BAR grande habilitada, la plataforma llegó a un caso límite de recursos. Los logs del SO mostraron intentos de reasignación de BAR y fallos ocasionales.
Algunos arranques caían silenciosamente al modo fallback; otros dejaban al driver de la GPU en un estado problemático.

La solución fue aburrida: actualización de firmware, una guía más estricta de población de ranuras y un paso explícito de verificación del lado del SO (tamaño de BAR en lspci) como puerta.
La suposición equivocada fue pensar que una casilla de UI es un contrato. Es una sugerencia.

Mini-historia 2: La optimización que se volvió en contra

Un pequeño equipo de ML ejecutaba inferencia acelerada por GPU en un pool compartido de estaciones—porque comprar servidores dedicados era «el próximo trimestre», que en corporativo significa «no sucederá pronto».
Notaron que algunas cargas tenían menor varianza de latencia en una máquina y preguntaron qué era diferente.

Alguien descubrió que Resizable BAR estaba habilitado en esa caja y decidió activarlo en todas. Sin control de cambios. Sin despliegue por etapas. Solo un viernes por la tarde de «mejora de rendimiento».
El tipo de decisión que crea planes de fin de semana para otras personas.

El lunes, un subconjunto de nodos comenzó a lanzar resets de GPU bajo alta concurrencia. No todos. Solo aquellos con un modelo particular de tarjeta de captura instalada para otro proyecto.
Los resets parecían inestabilidad del driver, así que la primera reacción fue actualizar drivers. Eso no ayudó.

Eventualmente emergió el patrón: los sistemas con la tarjeta de captura tenían un layout MMIO más apretado, y habilitar la BAR grande empujó la plataforma a una configuración técnicamente legal pero prácticamente frágil.
Bajo carga, las rutas de recuperación de errores eran problemáticas. Deshabilitar ReBAR estabilizó todo.

La vuelta no fue que Resizable BAR sea «malo». Fue que el equipo optimizó una dimensión (posible rendimiento) e ignoró las restricciones de recursos de la plataforma y la heterogeneidad.
Un interruptor aplicado a toda la flota sin conciencia topológica no es optimización; es improvisación.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un grupo de producto tenía un laboratorio mixto Windows y Linux para pruebas de motores de juego. Tenían una política: cualquier ajuste de BIOS a nivel de rendimiento requiere
una ejecución registrada antes/después en una carga representativa, más un artefacto legible por máquina almacenado con el informe de prueba.

Sonaba burocrático hasta que dejó de serlo. Llegó una nueva versión de BIOS y un lote de máquinas se actualizó. La canalización nocturna de rendimiento del laboratorio
marcó una pequeña regresión en la consistencia del tiempo de cuadro en un subconjunto de sistemas. El FPS promedio estaba bien. La «sensación» no.

Como el laboratorio almacenaba artefactos de verificación, fue trivial ver qué había cambiado: el tamaño de la BAR volvió a una ventana pequeña tras la actualización del BIOS,
aunque la UI del BIOS aún mostrara Resizable BAR habilitado. La actualización de UEFI también había cambiado el comportamiento de CSM en algunos perfiles.

La solución fue rápida: imponer arranque solo UEFI, re-aplicar los ajustes correctos de firmware y bloquear esa compilación de BIOS hasta validación. Sin conjeturas, sin
«quizás sea el driver». Solo evidencia y acción.

La práctica aburrida—tratar los interruptores de firmware como riesgos de deriva de configuración—salvó días de discusión y mantuvo la credibilidad del laboratorio.

Errores comunes: síntomas → causa raíz → solución

1) «La BIOS dice habilitado, pero el rendimiento no cambió»

Síntomas: Sin mejora; herramientas del SO aún muestran BAR ~256MB; benchmarks sin cambios.
Causa raíz: Arranque CSM/Legacy, Above 4G Decoding faltante o firmware que no asigna MMIO grande por lo que la BAR nunca se negoció.
Solución: Arrancar UEFI, desactivar CSM, habilitar Above 4G Decoding + ReBAR, actualizar BIOS y luego confirmar con lspci -vv el tamaño de la BAR.

2) «Habilité ReBAR y ahora pantallas negras aleatorias / resets de driver»

Síntomas: Caídas intermitentes de pantalla, logs de reset de GPU, inestabilidad bajo carga.
Causa raíz: Caso límite de asignación MMIO/recursos con otros dispositivos PCIe; a veces agravado por risers/configuración de bifurcación.
Solución: Actualizar BIOS, simplificar topología PCIe, mover tarjetas a otras ranuras, probar con dispositivos mínimos; si sigue inestable, desactivar ReBAR.

3) «Funciona hasta que añadimos otra tarjeta NVMe»

Síntomas: ReBAR deja de negociarse o el sistema no pasa POST al añadir dispositivos PCIe.
Causa raíz: Agotamiento de espacio MMIO o mala política de asignación del firmware.
Solución: Asegurar Above 4G Decoding, actualizar firmware, reducir tarjetas add-in o elegir placas con mejor manejo de recursos PCIe.

4) «El stutter empeoró aunque el FPS promedio mejoró»

Síntomas: FPS promedio más alto, pero aumento de picos de hitching.
Causa raíz: Moviste el cuello de botella: ahora el almacenamiento I/O, presión de memoria, compilación de shaders o planificación de CPU dominan los tiempos de cuadro.
Solución: Medir utilización de almacenamiento (iostat), presión de RAM (/proc/meminfo), saturación por núcleo (mpstat) y atender eso.

5) «La VM con passthrough no ve ReBAR»

Síntomas: El host muestra BAR grande, el invitado muestra BAR pequeña o falla al arrancar la VM con errores de recursos.
Causa raíz: Firmware/config de VM no permite MMIO grande; VFIO no puede reservar la BAR grande; restricciones IOMMU.
Solución: Usar UEFI (OVMF) para el invitado, configurar ventanas MMIO grandes, asegurar que el host pueda reservar recursos; de lo contrario acepta que no funcionará en esa topología.

6) «Lo habilitamos en toda la flota y algunas máquinas perdieron la pantalla al arrancar»

Síntomas: Sin salida de vídeo en el arranque, o atascado en el splash del proveedor.
Causa raíz: Problemas de compatibilidad firmware/option ROM, especialmente con GPUs antiguas o ajustes legacy mezclados.
Solución: Revertir mediante reset de BIOS, actualizar VBIOS de GPU, imponer arranque solo UEFI y desplegar en canarios.

Broma #2: Si tu plan de cambios es «flipar el interruptor del BIOS y vibear», felicitaciones—has inventado Chaos Engineering para quien odia paneles.

Listas de verificación / plan paso a paso

Plan de cambio para una sola estación (seguro y rápido)

Capturar línea base. Registra versión de driver, versión de BIOS y un benchmark representativo o traza de carga (promedio + 1% lows/tiempos de cuadro).
Actualizar firmware primero. Si no estás en un BIOS razonablemente actual, no pierdas tiempo. Hay demasiados bugs de asignación allí.
Cambiar a UEFI-only. Desactiva CSM/arranque Legacy. Verifica que Linux muestre /sys/firmware/efi.
Habilitar Above 4G Decoding. Este es el ajuste de «hacer espacio».
Habilitar Resizable BAR. Guardar, reiniciar.
Verificar en SO. Usa lspci -vv y confirma una BAR prefetechable grande y la capacidad Resizable BAR con el tamaño negociado.
Re-ejecutar la misma carga. Compara rendimiento promedio y latencia en cola/consistencia de tiempo de cuadro.
Decidir: mantener o revertir. Mantén si mejora la métrica que te importa sin añadir inestabilidad. Revierte si añade fragilidad o no ayuda.

Plan de despliegue canario para una flota (lo que hacen realmente los SRE)

Segmentar la flota por topología de hardware. La misma revisión de placa importa. El mismo VBIOS de GPU importa. La misma población de tarjetas add-in importa.
Elegir canarios por segmento. No un único equipo héroe. Al menos unos pocos por topología.
Definir métricas de éxito. No «se siente más rápido». Escoge medibles: tiempo de cuadro p95, tiempo de compilación, duración de export, tasa de crashes.
Automatizar la verificación. Recopila fragmentos de lspci -vv o líneas de sysfs como artefactos.
Desplegar con plan de rollback. Documenta cómo revertir ajustes de BIOS de forma remota o mediante procedimiento presencial.
Vigilar fallos correlacionados. Especialmente con dispositivos PCIe adicionales y después de actualizaciones de firmware.

Regla práctica

Habilitar si puedes verificar BAR grande en el SO y tu carga es sensible a transmisión/transferencias CPU.
No molestes si estás limitado por GPU y estable; probablemente persigues ruido.
Deshabilitar si ves inestabilidad o si habilitarlo rompe una topología PCIe previamente funcional.

Preguntas frecuentes

1) ¿SAM es diferente de Resizable BAR?

No fundamentalmente. SAM es la implementación de AMD de Resizable BAR más validación de plataforma y valores por defecto. El mecanismo subyacente es PCIe Resizable BAR.

2) ¿Necesito Above 4G Decoding?

En la mayoría de sistemas reales, sí. Los mapeos de BAR grandes consumen espacio MMIO, y Above 4G Decoding permite al firmware asignar ese espacio por encima de 4 GB donde hay sitio.

3) ¿Por qué mi BIOS marca «habilitado» pero Linux aún muestra una BAR pequeña?

Causas comunes: estás arrancando en legacy/CSM, el firmware falló la asignación por otros dispositivos, o la combinación GPU VBIOS/firmware no la negoció.
Confía en lspci -vv más que en la casilla.

4) ¿Puede Resizable BAR reducir el stutter?

Puede, en cargas donde las transferencias CPU↔GPU y la sobrecarga de remapeo contribuyen a picos de tiempo de cuadro. Pero el stutter suele ser causado por almacenamiento, presión de memoria,
compilación de shaders o planificación de CPU. Mide antes de atribuir mejoras a la BAR.

5) ¿Ayuda en cargas de cómputo/ML?

A veces, especialmente si el flujo de trabajo hace staging frecuente de datos desde memoria CPU a memoria GPU en patrones que se benefician de mapas mayores.
Muchas tuberías ML están dominadas por cómputo GPU y ancho de banda de memoria GPU, donde el tamaño de BAR cambia poco.

6) ¿Es seguro habilitarlo en una flota de estaciones?

Es seguro si lo tratas como cualquier cambio de firmware: haz etapas, verifica la negociación a nivel de SO y vigila tasas de crash/pantallazos. Es inseguro si lo activas
en hardware heterogéneo y lo consideras «igual».

7) ¿Por qué algunos fabricantes lo activan solo para ciertos juegos?

Porque el ecosistema es desordenado. Algunos engines y rutas de driver se benefician; otros pueden sufrir regresiones; algunos pueden disparar casos límite. Las políticas por perfil
son una táctica pragmática de control de riesgo.

8) ¿Puedo usarlo con passthrough de GPU a una VM?

Depende. El host puede soportarlo, pero el invitado necesita suficiente espacio MMIO y una configuración de firmware UEFI que pueda mapear la BAR grande. Muchos setups de passthrough requieren
configuración explícita de «MMIO grande».

9) ¿Cuál es la mejor prueba única de que funciona en Linux?

Un tamaño prefetechable grande en lspci -vv (a menudo varios GB) más la capacidad «Resizable BAR» mostrando un tamaño actual no trivial.

10) Si no ayuda, ¿debería apagarlo?

Si no ves beneficio y valoras máxima previsibilidad, sí—desactívalo y simplifica. Si es estable y gestionas un entorno de cargas mixtas, mantenerlo activado es razonable siempre
que puedas verificar que sigue habilitado tras actualizaciones de firmware.

Conclusión: pasos prácticos a seguir

Resizable BAR/SAM es uno de esos raros interruptores de plataforma que puede mejorar legítimamente cargas reales—cuando la carga es sensible y la plataforma asigna recursos limpiamente.
También es una gran manera de exponer firmware frágil, topologías PCIe saturadas y hábitos de benchmark que ignoran la latencia de cola.

Verifica, no asumas. Confirma el tamaño de la BAR en el SO. Si no es grande allí, no está habilitado.
Mide lo correcto. Usa tiempos de cuadro o latencias p95/p99, no solo rendimiento promedio.
Arregla los cuellos de botella obvios primero. Ancho/velocidad del enlace PCIe, saturación de almacenamiento y presión de memoria frecuentemente dominan los «debates sobre BAR».
Despliega como un adulto. Haz canarios por topología de hardware, controla la deriva de firmware y ten un plan de rollback.

Si quieres una política de una línea: habilita Resizable BAR donde puedas probar que se negoció y mejora la métrica que realmente sienten tus usuarios; si no, déjalo apagado y disfruta
de una cola de incidentes más tranquila.