Resizable BAR / SAM: маленький перемикач, що може дати великий приріст

January 16, 2026 • February 3, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ви відправляєте нову відеокарту у парк робочих станцій, запускаєте бенчмарки і… нічого. Або ще гірше: декілька машин стали швидшими, кілька отримали дивні підгальмовування,
а одна взагалі вирішила завантажуватися лише по вівторках. У назві тікета — «регрес продуктивності графіки», але корінь проблеми — біосьовський перемикач, який більшість людей
трактує як декоративну приладку.

Resizable BAR (а у AMD під брендом Smart Access Memory / SAM) саме такий перемикач: невеликий, легкий до неправильного налаштування та здатний
помітно вплинути на реальні робочі навантаження. Це також чудовий спосіб дізнатися, скільки шарів лежить між «додаток просить текстуру» і «байти доходять до GPU».

Що насправді змінює Resizable BAR / SAM

Пристрої PCI Express мають області, що відображаються у пам’ять, які називають BAR: Base Address Registers. Саме через них CPU (і ОС) відображає регістри пристрою та
іноді фрагменти пам’яті пристрою у адресний простір системи. Історично GPU дозволяли CPU бачити лише невелике «вікно» своєї VRAM у будь-який момент — зазвичай близько 256 МБ —
тому CPU міг безпосередньо відобразити лише частину VRAM. Якщо CPU потрібно було звернутися до іншої частини VRAM, вікно доводилося перемаповувати.

Resizable BAR — це можливість у специфікації PCIe, яка дозволяє прошивці/ОС домовитися про більший розмір BAR для пристрою — потенційно відобразивши значно більшу частину
VRAM у адресний простір CPU одночасно. Це може зменшити накладні витрати на перемапування та покращити пропускну здатність для навантажень, що залежать від
передач, потокового завантаження ресурсів і великої кількості дрібних трансферів. Іноді це нічого не дає. Іноді це важливо.

Smart Access Memory (SAM) від AMD — це не інша технологія; це брендування Resizable BAR разом із платформною валідацією й біосьовим прапорцем, який
створює відчуття «ви щось розблокували». У NVIDIA це все ще називають Resizable BAR, зазвичай увімкненим через BIOS плюс профілі драйвера/ігор.

Практична ментальна модель: Resizable BAR не робить GPU швидшим. Воно змінює ефективність того, як CPU адресує й підгодовує пам’ять GPU.
Якщо вузьке місце — пропускна здатність шейдерів, ядра трасування променів або сам GPU вже насичує свою пам’ять, розмір BAR вам не допоможе.
Якщо ж вузьке місце — «CPU виконує багато дрібних операцій з VRAM під час стримінгу», розмір BAR може дати результат.

Менше маркетингу, більше суті: розмір вікна і перемапування

Без Resizable BAR CPU бачить невелике вікно VRAM. Уявіть склад з поштовим отвором: можна передавати коробки, але лише по одній і постійно змінювати, на яку полицю вказує отвір.
Resizable BAR збільшує цей отвір, іноді настільки, що видно увесь склад. Накладна обробка зменшується. Чи перетвориться це на FPS — залежить від того, чи була
«накладна обробка» дійсно вашою обмежуючою ланкою.

Цитата, бо операційникам потрібна твердість

Надія — це не стратегія. — Ед Кетмулл (цитата, уживана в інженерних колах)

Факти та контекст: чому це з’явилося

Ви не отримаєте такий біосьовський перемикач без довгого ланцюжка компромісів. Ось конкретні факти та історичні підказки, які корисно знати перед тим, як починати твічити перемикачі у проді.

BAR з’явилися раніше за сучасні GPU. BAR — частина специфікації PCI з епохи, коли «пам’ять пристрою» часто означала регістрові вікна й невеликі буфери, а не десятки гігабайт VRAM.
256 МБ стало де-факто апертурою GPU. Протягом років багато платформ відображали 256 МБ prefetchable BAR для GPU, що було «достатньо», коли розміри VRAM і патерни трафіку CPU↔GPU були іншими.
Resizable BAR — це можливість PCIe, не винахід вендора. Механізм існує в PCIe, але широке споживче увімкнення затримувалося, бо прошивка, ОС і драйвери мали поводитися погоджено.
“Above 4G Decoding” — про адресний простір, а не про продуктивність. Це дозволяє прошивці розміщувати PCIe MMIO вище межі 4 ГБ, що важливо, коли великі BAR конфліктують з обмеженими 32-бітними MMIO вікнами.
UEFI має значення, бо конвеєр завантаження виділяє ресурси. Старі шляхи завантаження Legacy/CSM і старі option ROM часто ускладнювали або робили неможливими великі гнучкі MMIO-виділення.
Серверні плати перейнялися цим раніше, ніж геймерські. Платформи високого класу, які регулярно відображають великі MMIO-регіони (HBA, NIC з SR-IOV, акселератори), штовхнули екосистему до більш розумного поведінки розподілу ресурсів.
Драйвери жорстко керують поведінкою. NVIDIA історично вмикала Resizable BAR для конкретних ігор/профілів, бо «працює на папері» не те саме, що «працює в 500 рушіях з 500 особливостями».
Віртуалізація ускладнює ситуацію. Passthrough, IOMMU-групи та прошивка у віртуальній машині можуть завадити великим BAR-мепінгам навіть якщо хост їх підтримує.
Це не лише для ігор. Деякі конвертаційні та обчислювальні конвеєри виграють, коли взаємодія CPU-сторони і управління пам’яттю GPU інтенсивна.

Коли це допомагає (а коли — ні)

Де Resizable BAR зазвичай допомагає

Навантаження з інтенсивним потоковим завантаженням ресурсів: відкриті світи, великі сцени, часте потокове завантаження текстур/геометрії.
Рендеринг, обмежений CPU при великій кількості передач: CPU витрачає час на координацію завантажень і переходів ресурсів.
Деякі програми для контенту: великі проєкти, текстури високої роздільної здатності, часті перемикання кешу — залежно від архітектури програми.
Бенчмарки, що імітують реальний стримінг: не лише «максимальне навантаження шейдерів», а й «завантажити/звільнити/завантажити знову».

Де зазвичай не допомагає

Чисто GPU-зв’язані сценарії (висока роздільна здатність + інтенсивні шейдери), де GPU вже є обмеженням.
Навантаження, що домінуються локальною пропускною здатністю пам’яті GPU, а не транзакціями CPU↔GPU.
Дуже старі рушії або програми, які не навантажують поведінку відображення VRAM з боку CPU.
Системи, що обмежені розкладкою ліній PCIe (x8 проти x16, uplink чіпсету) або I/O підсистемою зберігання, що постачає ресурси.

Реалістична перевірка: це ручка, не диво

Resizable BAR може дати відчутні підвищення в деяких тайтлах і робочих потоках, але це не гарантована «безкоштовна» кнопка продуктивності. Причина, чому це стало хайпом, проста: це один з небагатьох змін на рівні платформи,
який може показати вимірювані прирости без купівлі нової карти. Це не робить його універсально корисним; це робить його спокусливим.

Жарт №1: Resizable BAR — це як дати GPU більшу соломинку: чудово, якщо ви були обмежені соломинкою, марно, якщо ви були обмежені напоєм.

Жорсткі вимоги та нюанси сумісності

У виробничих середовищах — так, навіть у «продакшен-ігрових» лабораторіях — ви хочете детермінованої поведінки. Resizable BAR має передумови.
Якщо будь-яка з них не виконана, ви отримаєте часткове увімкнення, відсутність увімкнення або увімкнення разом із дивними побічними ефектами.

Вимоги платформи (звичні підозрювані)

Завантаження через UEFI (CSM зазвичай вимкнено).
Увімкнено Above 4G Decoding у BIOS/UEFI.
Увімкнено Resizable BAR у BIOS/UEFI.
Підтримка GPU VBIOS для Resizable BAR.
Прошивка материнської плати, що розподіляє MMIO адекватно (тут «остання версія BIOS» перестає бути необов’язковою).
Підтримка ОС і драйвера (Windows і сучасні ядра Linux зазвичай підтримують це, але драйвери можуть все ще обмежувати використання).

Нюанси, на які варто звернути увагу

Змішані GPU-середовища: увімкнене iGPU + dGPU + додаткові PCIe-пристрої можуть штовхнути розподіл MMIO у крайові випадки.
Безліч PCIe-пристроїв: NIC, HBA, NVMe AIC, карти захоплення — MMIO-простір заповнюється.
Віртуалізація/passthrough: гостьова ОС може не вміти мапити великі BAR, або гіпервізор може їх обрізати.
Старі option ROM: очікування спадщини ROM можуть конфліктувати з великими мапами BAR.
Підозрілий інтерфейс «увімкнено»: деякі прошивки показують прапорець, але реально не виділяють більший BAR.

Швидкий план діагностики (перший/другий/третій)

Якщо ви налагоджуєте скаргу на продуктивність і хтось згадує Resizable BAR, вам потрібно швидко відповісти на три питання:
(1) чи воно справді увімкнене, (2) чи чутливе навантаження, і (3) чи щось інше не є вузьким місцем.

По-перше: підтвердіть увімкнення наскрізь

Перевірте налаштування BIOS: Above 4G Decoding, Resizable BAR, CSM/Legacy boot.
В ОС підтвердіть, що розмір BAR більший за спадкове вікно (часто > 256M).
Підтвердіть, що драйвер його розпізнає (NVIDIA Control Panel у Windows; sysfs/lspci у Linux).

По-друге: переконайтеся, що ви вимірюєте правильне вузьке місце

Завантаження GPU, використання VRAM, завантаження CPU по ядрах.
Консистентність часу кадру (підгальмовування vs середній FPS).
Ширина/швидкість лінку PCIe (x16 Gen4 vs x8 Gen3 може домінувати результат).

По-третє: шукайте конфлікти розподілу ресурсів

dmesg/Windows event logs на предмет попереджень про розподіл PCI ресурсів.
IOMMU/ACS кверки, якщо є passthrough.
Інші пристрої, що споживають MMIO-простір (кілька NVMe AIC, SR-IOV NIC).

Якщо ви не можете довести, що воно увімкнене, припиніть сперечатися про бенчмарки. Якщо ви довели, що воно увімкнене, але нічого не змінюється, вважайте, що ви не обмежені BAR.
Рухайтеся далі.

Практичні завдання з командами, виводами та рішеннями

Це ті завдання, які я реально виконую, коли хтось каже «Resizable BAR увімкнено» або «SAM зламав мою машину». Кожне завдання містить реалістичну команду,
приклад виводу, що означає вивід, і яке рішення він диктує. Команди орієнтовані на Linux, бо Linux показує правду без UI-драми.
Ви можете адаптувати логіку під Windows-інструменти, якщо там працюєте.

Завдання 1: Знайти PCI-адресу 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)

Значення: GPU знаходиться за адресою 01:00.0. Цю адресу ви використовуватимете для подальшого інспектування PCIe.
Рішення: Зафіксуйте правильний пристрій; не вгадуйте, коли є декілька GPU.

Завдання 2: Перевірити розміри BAR і чи вони «великі»

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]

Значення: 16G prefetchable BAR — сильний індикатор того, що Resizable BAR активний і відображає великий апертур VRAM.
Спадкова поведінка часто ~256M. Ваші точні номери регіонів можуть відрізнятися.
Рішення: Якщо ви все ще бачите лише маленький prefetchable регіон, повертайтеся до передумов прошивки/режиму завантаження.

Завдання 3: Підтвердити, що можливість 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

Значення: Пристрій рекламує можливість Resizable BAR і погодив 16GB мапу.
Рішення: Якщо можливість відсутня, ймовірно потрібне оновлення VBIOS GPU або GPU просто не підтримує її.

Завдання 4: Швидко перевірити режим завантаження (UEFI vs legacy)

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

Значення: Ви завантажені через UEFI.
Рішення: Якщо отримаєте «Legacy», вимкніть CSM/Legacy boot і перевстановіть або конвертуйте завантаження, інакше увімкнення великого BAR часто не вдається.

Завдання 5: Підтвердити, що ядро побачило виділення ресурсів Above 4G без помилок

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]

Значення: Ядро успішно призначило великий 64-бітний prefetchable вікно.
Рішення: Якщо бачите «not enough MMIO resources» або помилки призначення BAR, очікуйте нестабільності або відкат BAR.

Завдання 6: Перевірити ширину і швидкість PCIe-лінку (мовчазний вбивця)

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)

Значення: Ви працюєте на еквіваленті Gen4 x16 (16GT/s) і повній ширині. Добре.
Рішення: Якщо тут показано x8 або Gen3, виправте посадку, вибір слота, налаштування біфуркації BIOS, райзери або трасування чіпсета перш ніж звинувачувати BAR.

Завдання 7: Перевірити стан IOMMU (важливо для passthrough та деяких платформ)

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

Значення: IOMMU увімкнено. Добре для ізоляції, іноді погано для шляхів з чутливими до затримки налаштуваннями, якщо неправильно сконфігуровано.
Рішення: Якщо ви робите GPU passthrough і великий BAR не «приживається», можливо потрібні налаштування гіпервізора, які дозволяють великі MMIO.

Завдання 8: Переглянути sysfs-мапінг ресурсів для GPU

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

Значення: Третій рядок показує величезний змеплений регіон (0x4000… до 0x43ff…), що відповідає великому BAR.
Рішення: Якщо prefetchable регіон малий або відсутній, ваше увімкнення не є реальним.

Завдання 9: Підтвердити, що драйвер завантажився і який GPU активний

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

Значення: Завантажені модулі ядра NVIDIA.
Рішення: Якщо ви на неправильному драйвері (nouveau vs nvidia, або невідповідний стек amdgpu), поведінка BAR і продуктивність будуть непередбачувані.

Завдання 10: Перевірити розмір VRAM і базові статистики під час виконання (саніті-чек)

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

Значення: Підтверджує, що ви опитуєте правильний GPU і що PCIe-лінк здоровий.
Рішення: Якщо gen/width низькі під навантаженням, перевірте управління живленням або налаштування BIOS «PCIe speed».

Завдання 11: Виміряти поведінку CPU vs GPU під час запуску (швидко і грубо)

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

Значення: Одне ядро завантажене на максимум. Це пахне вузьким місцем на рівні CPU-підготовки або однопотоковою ділянкою навантаження.
Рішення: Якщо одне-дві ядра завантажені, а GPU використовується мало, Resizable BAR може трохи допомогти — але також варто шукати причини на боці CPU.

Завдання 12: Переконатися, що сховище не є реальним «потоковим» вузьким місцем

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

Значення: NVMe пристрій на ~94% завантаженості з нетривіальним часом очікування. Потокове завантаження ресурсів може бути обмежене сховищем.
Рішення: Якщо сховище насичене, зміни BAR не виправлять хитання; спочатку вирішіть I/O (швидше сховище, кращий кеш, менше конкуренції).

Завдання 13: Перевірити hugepages/THP і базовий тиск пам’яті (підгальмовування може бути через пам’ять)

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

Значення: Низький об’єм доступної пам’яті і swap майже вичерпаний. Це може спричиняти жорсткі стрибки часу кадру, не пов’язані з BAR.
Рішення: Якщо є тиск пам’яті, виправте це перш ніж приписувати поліпшення/регреси BAR.

Завдання 14: Перерахуйте інші PCIe-пристрої, що конкурують за 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)

Значення: Кілька пристроїв можуть вимагати MMIO-вікна; з великим BAR розподіл може стати щільним.
Рішення: Якщо увімкнення BAR не вдається на «завантажених» системах, але працює на мінімальних, розгляньте зменшення кількості пристроїв, зміну слотів або оновлення прошивки.

Завдання 15: Перевірити, чи ядро обрізало розміри BAR (часто буває з квірками)

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

Значення: Ядро явно змінило розмір BAR.
Рішення: Якщо бачите рядки «failed to resize», ви не отримуєте функцію, навіть якщо BIOS каже «Enabled».

Завдання 16: (Віртуалізація) Перевірити, чи QEMU/KVM готові до великих BAR на хості

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]

Значення: VFIO не може зарезервувати цей великий BAR-вікно для passthrough у поточній конфігурації.
Рішення: Потрібно налаштувати гіпервізор/прошивку VM (наприклад, дозволити великі MMIO, OVMF, адресний простір гостя) або погодитися, що у гостя великого BAR не буде.

Три корпоративні міні-історії з польових випадків

Міні-історія 1: Інцидент через неправильне припущення

Медіакоманда розгорнула нові робочі станції для монтажерів. Та ж модель GPU, той сам драйвер, той сам образ ОС. Єдина відмінність — ревізія материнської плати, яку закупівля потай замінила, бо «еквівалентна».

Пілотні машини показали поліпшення у скролінгу таймлайну та стабільності перегляду після увімкнення Resizable BAR. Тож план розгортання сказав:
«Увімкнути ReBAR + Above 4G, валідовати бенчмарком, відправляти». Цей план припустив, що «увімкнено у BIOS» означає «увімкнено насправді».

За тиждень з’явилися тікети підтримки: періодичні чорні екрани, випадкові падіння додатків під час експорту і кілька машин, що жорстко зависали під навантаженням. Бенчмарк, який використовували для валідації, не викликав проблему; реальна монтажна робота викликала.

Корінь проблеми не був містичним. На «еквівалентних» платах прошивка виділяла PCIe-ресурси інакше, коли встановлено кілька NVMe-дисків і 10GbE NIC. З увімкненим великим BAR платформа стикалася з краєм ресурсу.
Журнали ОС показували спроби переназначення BAR і часом помилки. Деякі завантаження повертавалися до запасного режиму непомітно; інші залишали драйвер GPU у поганому стані.

Виправлення було нудним: оновлення прошивки, чіткіша політика розміщення карт у слотах і явний крок перевірки на ОС (розмір BAR у lspci) як умова пропуску. Неправильне припущення було в тому, що UI-перемикач — це контракт. Насправді це пропозиція.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Невелика ML-команда запускала прискорене на GPU inference на загальному пулі робочих станцій — бо купити виділені сервери планували «в наступному кварталі», що корпоративною мовою означає «не скоро». Вони помітили, що деякі навантаження мали меншу дисперсію затримки на одній машині і запитали, у чому різниця.

Хтось виявив, що на тій машині увімкнено Resizable BAR, і вирішив увімкнути його скрізь. Без контролю змін. Без поступового розгортання. Просто п’ятнична «оптимізація продуктивності». Тип рішення, що створює плани для вихідних інших людей.

В понеділок частина вузлів почала кидати скиди GPU під високою конкурентністю. Не всі. Лише ті, де встановлено певну модель карти захоплення для іншого проєкту. Скиди виглядали як нестабільність драйвера, тож перша реакція була оновити драйвери. Це не допомогло.

Зрештою виявився патерн: системи з картою захоплення мали щільніший MMIO-layout, і увімкнення великого BAR штовхнуло платформу у конфігурацію, що була юридично коректною, але практично крихкою. Під навантаженням шляхи відновлення від помилок працювали неохайно. Вимкнення ReBAR стабілізувало все.

Повернення бумерангом не означає, що Resizable BAR «поганий». Воно означає, що команда оптимізувала один вимір (потенційну пропускну здатність) і проігнорувала обмеження платформи й гетерогенність. Перемикач, застосований на весь парк без урахування топології, — це не оптимізація, а імпровізація.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Продуктова команда вела лабораторію змішаних Windows і Linux машин для тестування ігрового рушія. У них була політика: будь-який біосьовський перформанс-перемикач вимагає записаного «до/після» запуску на репрезентативному навантаженні, плюс машинозчитуваний артефакт перевірки, збережений разом із тестовим звітом.

Це звучало бюрократично, поки не перестало. Прийшло нове BIOS-оновлення, і пакет машин отримав оновлення. Нічний пайплайн продуктивності лабораторії позначив невеликий регрес у консистентності часу кадру на підмножині систем. Середній FPS був у нормі. «Відчуття» — ні.

Оскільки лабораторія зберігала артефакти верифікації, було просто побачити, що змінилося: розмір BAR повернувся до малого вікна після оновлення BIOS, хоча в UI BIOS і далі показував Resizable BAR увімкненим. Оновлення UEFI також змінило поведінку CSM у деяких профілях.

Виправлення було швидким: зафіксувати UEFI-only завантаження, повторно застосувати правильні налаштування прошивки і заблокувати ту збірку BIOS до валідації. Ніяких домислів, ніякого «може бути це драйвер». Просто докази, потім дія.

Сумна, але правильна практика — трактувати налаштування прошивки як ризики дрейфу конфігурації — заощадила дні суперечок і зберегла довіру до лабораторії.

Типові помилки: симптом → корінь → виправлення

1) «BIOS каже увімкнено, але продуктивність не змінилася»

Симптоми: Немає приросту; інструменти ОС все ще показують ~256MB-ish BAR; бенчмарки незмінні.
Корінь: CSM/Legacy завантаження, відсутній Above 4G Decoding, або прошивка не змогла виділити великий MMIO, тож BAR ніколи не погодився.
Виправлення: Завантаження через UEFI, відключити CSM, увімкнути Above 4G Decoding + ReBAR, оновити BIOS, потім підтвердити через lspci -vv розмір BAR.

2) «Увімкнули ReBAR і тепер випадкові чорні екрани / скиди драйвера»

Симптоми: Періодичні зникнення зображення, журнали скидів GPU, нестабільність під навантаженням.
Корінь: Крайові випадки розподілу MMIO/ресурсів з іншими PCIe-пристроями; іноді посилюється райзерами/біфуркацією.
Виправлення: Оновити BIOS, спростити топологію PCIe, перемістити карти в інші слоти, тестувати з мінімальним набором пристроїв; якщо нестабільність залишається — вимкнути ReBAR.

3) «Працювало, поки не додали ще один NVMe-контролер»

Симптоми: ReBAR перестає погоджуватися або система не проходить POST після додавання PCIe-пристроїв.
Корінь: Виснаження MMIO-простору або погана політика прошивки щодо розподілу ресурсів.
Виправлення: Переконатися в увімкненні Above 4G Decoding, оновити прошивку, зменшити кількість карт, або обрати плати з кращою обробкою PCIe-ресурсів.

4) «Підгальмовування погіршилося, хоча середній FPS покращився»

Симптоми: Вищий середній FPS, але збільшилися стрибки часу кадру.
Корінь: Ви перемістили вузьке місце: тепер домінують I/O зберігання, тиск пам’яті, компіляція шейдерів або планування CPU.
Виправлення: Виміряти використання сховища (iostat), тиск пам’яті (/proc/meminfo), завантаження CPU по ядрах (mpstat) і усунути ці проблеми.

5) «Passthrough VM не бачить ReBAR»

Симптоми: Хост показує великий BAR, гість показує маленький BAR або VM не стартує з помилками ресурсів.
Корінь: Гостьова прошивка/конфігурація VM не дозволяє великі MMIO; VFIO не може зарезервувати великий BAR; обмеження IOMMU.
Виправлення: Використовуйте UEFI (OVMF) для гостя, налаштуйте великі MMIO-вікна, переконайтеся, що хост може резервувати ресурси; інакше прийміть, що в цій топології не працюватиме.

6) «Увімкнули по всьому парку і деякі машини втратили вивід на екрані при завантаженні»

Симптоми: Немає відео на етапі POST або застрягання на заставці вендора.
Корінь: Проблеми сумісності прошивки/option ROM, особливо зі старими GPU або змішаними legacy-налаштуваннями.
Виправлення: Повернути через скидання BIOS, оновити VBIOS GPU, вимагати UEFI-only і впроваджувати в канарках.

Жарт №2: Якщо ваш план змін — «перемкнути прапорець у BIOS і кайфувати», вітаю — ви винайшли Chaos Engineering для людей, які ненавидять дашборди.

Чек-листи / покроковий план

План змін для однієї робочої станції (безпечний і швидкий)

Захопіть базову лінію. Зафіксуйте версію драйвера, версію BIOS і один репрезентативний бенчмарк або трасу робочого навантаження (середнє + 1% lows/часи кадру).
Спочатку оновіть прошивку. Якщо BIOS не відносно свіжий — не починайте. Багато багів з розподілом ресурсів живуть у старій прошивці.
Переключіться на UEFI-only. Вимкніть CSM/Legacy boot. Підтвердіть, що Linux показує /sys/firmware/efi.
Увімкніть Above 4G Decoding. Це налаштування «звільни місце».
Увімкніть Resizable BAR. Збережіть, перезавантажтеся.
Підтвердіть в ОС. Використайте lspci -vv і підтвердіть великий prefetchable BAR і поточний розмір, погоджений у Resizable BAR.
Повторно запустіть те саме навантаження. Порівняйте середню пропускну здатність і хвостову латентність/консистентність часу кадру.
Рішення: залишити чи відкотити. Залишайте, якщо поліпшилося метрика, яка важлива, без додання нестабільності. Відкочуйте, якщо додає невпевненості або не допомагає.

План канаркового розгортання для парку (що реально робить SRE)

Сегментуйте парк за апаратною топологією. Важлива та сама ревізія материнської плати. Важливий той сам VBIOS GPU. Важлива та сама конфігурація додаткових карт.
Виберіть канарки по сегменту. Не одна «геройська» машина. Принаймні кілька на топологію.
Визначте метрики успіху. Не «відчувається швидше». Обирайте вимірювані: p95 часу кадру, час компіляції, тривалість експорту, частота падінь.
Автоматизуйте верифікацію. Збирайте фрагменти lspci -vv або рядки sysfs як артефакти.
Розгортайте з планом відкату. Документуйте, як відкотити налаштування BIOS дистанційно або руками.
Слідкуйте за корельованими збоями. Особливо при додаткових PCIe-пристроях і після оновлень прошивки.

Правило великого пальця

Увімкнути, якщо ви можете підтвердити великий BAR в ОС і ваше навантаження чутливе до потокової/CPU-передачі.
Не морочитися, якщо ви GPU-зв’язані і стабільні; ймовірно, ви женетеся за шумом.
Вимкнути, якщо бачите нестабільність або увімкнення ламає раніше робочу топологію PCIe.

FAQ

1) Чи відрізняється SAM від Resizable BAR?

Фундаментально — ні. SAM — це брендоване рішення AMD, що поєднує Resizable BAR з платформною валідацією і налаштуваннями за замовчуванням. Під капотом — PCIe Resizable BAR.

2) Чи потрібен Above 4G Decoding?

У більшості реальних систем — так. Великі мапи BAR споживають MMIO-простір, а Above 4G Decoding дозволяє прошивці виділяти простір вище 4 ГБ, де місця більше.

3) Чому BIOS показує «увімкнено», але Linux все ще бачить маленький BAR?

Звичні причини: ви завантажуєтесь у legacy/CSM, прошивка не змогла виділити ресурси через інші пристрої, або комбінація GPU VBIOS/прошивки не погодилася.
Довіряйте lspci -vv більше, ніж чекбоксу в UI.

4) Чи може Resizable BAR зменшити підгальмовування?

Може, в навантаженнях, де CPU↔GPU передачі та накладні витрати на перемапування впливають на час кадру. Але підгальмовування часто викликано сховищем, тиском пам’яті,
компіляцією шейдерів або плануванням CPU. Вимірюйте перш ніж приписувати заслугу BAR.

5) Чи допомагає це у обчисленнях/ML?

Іноді, особливо якщо робочий процес часто стадіює дані з пам’яті CPU у пам’ять GPU у патернах, що виграють від більших мап. Багато ML-конвеєрів домінуються GPU-обчисленням і пропускною пам’яті GPU, де зміни розміру BAR дають мало.

6) Чи безпечно увімкнути у парку робочих станцій?

Безпечно, якщо ставитися до цього як до зміни прошивки: робіть staged rollout, перевіряйте погодження на рівні ОС і слідкуйте за частотою падінь/чорних екранів. Небезпечно — якщо масово вмикати на гетерогенному парку і називати це «однаково».

7) Чому деякі вендори вмикають це лише для певних ігор?

Бо екосистема складна. Деякі рушії й шляхи драйвера виграють; деякі можуть регресувати; деякі тригерять крайові випадки. Вмикання за профілем — прагматична тактика контролю ризиків.

8) Чи можна використовувати це з GPU passthrough у VM?

Залежить. Хост може підтримувати це, але гість потребує достатнього MMIO-простору і UEFI-прошивку, що може відобразити великий BAR. Багато конфігурацій passthrough вимагають явної опції «великий MMIO».

9) Яке найкраще однолінійне підтвердження, що це працює на Linux?

Великий prefetchable BAR-розмір у lspci -vv (часто кілька ГБ) плюс можливість «Resizable BAR», що показує нетривіальний current size.

10) Якщо це не допомогло, чи потрібно вимикати?

Якщо ви не бачите користі і цінуєте максимальну передбачуваність — так, вимкніть і спростіть. Якщо це стабільно і ви керуєте змішаними навантаженнями,
залишати ввімкненим нормально, доки ви можете підтвердити, що воно лишається увімкненим після оновлень прошивки.

Висновок: практичні кроки далі

Resizable BAR / SAM — один із рідкісних перемикачів платформи, що може реально покращити робочі навантаження — коли навантаження чутливе, а платформа чисто розподіляє ресурси.
Це також чудовий спосіб виявити хитку прошивку, переповнені топології PCIe і звички бенчмаркінгу, що ігнорують хвостову латентність.

Підтвердіть, не припускайте. Підтверджуйте розмір BAR в ОС. Якщо там не великий — його немає.
Вимірюйте правильну річ. Використовуйте часи кадру або p95/p99 латентність, а не лише середню пропускну здатність.
Виправте очевидні вузькі місця спершу. Ширина/швидкість PCIe, насичення сховища і тиск пам’яті часто домінують у «BAR-дебатах».
Розгортайте як дорослі. Виконуйте канарки за апаратною топологією, відстежуйте дрейф прошивки і майте план відкату.

Якщо потрібна однолінійна політика: увімкнюйте Resizable BAR там, де ви можете довести, що воно погоджено і покращує метрику, яку відчувають користувачі; інакше вимикайте і насолоджуйтеся спокійнішою чергою інцидентів.