Свободные 8 ГБ VRAM превращают в swap — и латентность падает в 27 раз

Зачем отдавать дорогую видеопамять под ещё более дорогой своп

Идея, которую репозиторий nbd-vram вынес на главную HN (78 комментариев в треде), на первый взгляд звучит абсурдно: использовать VRAM видеокарты как пространство подкачки. Зачем менять дорогую RAM на ещё более дорогую видеопамять? Автор отвечает конкретным сценарием, а не философией.

Что именно делает утилита и откуда взялись цифры

Цель заявлена прямо: «Сделано для ноутбуков с гибридной графикой, распаянной памятью и без возможности апгрейда». На таких машинах дискретный NVIDIA-чип часто простаивает, пока встроенная графика рисует рабочий стол, а система при нехватке памяти свопится на SSD.

Механизм обходится без модуля ядра — и потому переживает обновления драйвера и ядра без пересборки:

• демон выделяет VRAM через CUDA driver API;
• отдаёт её как блочное устройство по Unix-сокету через протокол NBD (Network Block Device);
• ядро подключает /dev/nbdX, а дальше — обычные mkswap и swapon.

Путь данных автор описывает так: подсистема swap ядра → /dev/nbdX → драйвер nbd → Unix-сокет → демон nbd-vram → cuMemcpyHtoD/DtoH → VRAM.

Главное — бенчмарки на RTX 3070 Laptop (8 ГБ) против NVMe-свопа. На последовательных операциях VRAM проигрывает (запись 1,1 против 2,7 ГБ/с, чтение 2,3 против 2,9 ГБ/с), и по случайным 4K IOPS тоже (28,7k против 45,3k). Но там, где это важно для реального swap — латентность при редких одиночных обращениях: 335 мкс у VRAM против 9,05 мс у NVMe, то есть в ~27 раз быстрее. Автор отдельно поясняет, почему не пошёл прямым путём: P2P-API NVIDIA (nvidia_p2p_get_pages_persistent) на потребительских GeForce возвращает EINVAL — функция закрыта для Quadro и датацентровых карт, поэтому пришлось ходить через стандартный cuMemcpy.

Тред: «это очевидно должно быть в ядре, а не утилитой»

Первая же реакция — признание ниши при здоровом скепсисе.

«Ну да, это хотя бы отвечает на мой вопрос, зачем вообще менять дорогую RAM на действительно дорогую RAM :) Звучит нишево, но когда тебе это нужно — идея хорошая» — комментатор, уточнивший сценарий применения

Нашёлся и тот, кому идея легла на собственное железо:

«На моей рабочей машине 32 ГБ RAM и 32 ГБ VRAM, которая почти всё время простаивает, когда я не гоняю AI-модели. Так что идея совсем неплохая» — разработчик с 32 ГБ простаивающей VRAM

Самый принципиальный довод — что этим должно заниматься ядро, а не пользовательская утилита:

«Мне кажется очевидным, что это должно быть встроенной функцией ядра. Работа ядра — управлять ресурсами, а память GPU — такой же ресурс, и её можно использовать для многого из того, для чего используется обычная RAM» — участник, предложивший встроить это в ядро

Контрдовод: на Wayland это может уронить рабочий стол

Самое предметное возражение — про конфликт за VRAM. Если видеопамять занята под swap, что произойдёт, когда она внезапно понадобится самому графическому стеку?

«Как тут с обратным давлением? Что происходит с запросом на выделение VRAM, когда она занята под swap? На X11 не так страшно — буферы выделены заранее, но на Wayland аллокации куда динамичнее, и нехватка VRAM легко роняет весь десктоп. У меня уже было несколько таких падений на Hyprland с llama-server» — пользователь, ловивший краши десктопа из-за дефицита VRAM

И ещё одно сомнение в самих числах — что показанной пропускной способности подозрительно мало для PCIe 4.0:

«Sequential throughput ~1,3 ГБ/с — это ОЧЕНЬ мало. К тому же разве для свопа не важнее случайные чтения/записи?» — скептик про заниженную пропускную способность

Идея не новая — и список предшественников длинный

Тред быстро выкатил генеалогию: то же самое люди делали и раньше, разными API.

• Через OpenCL — vramblk, «я реализовал ту же идею; производительность так себе, это далеко не чудо»;
• старый трюк со swap on video RAM через MTD/phram-драйверы Linux, упомянутый со ссылкой на ArchWiki;
• готовый nbdkit-vram-plugin на OpenCL, работающий и на AMD;
• под Windows — экспериментальный GpuRamDrive.

Для кого это реально: узкая ниша, а не «теперь у вас больше памяти»

Итог из треда трезвее заголовка. Это не «бесплатная память за 90% потери скорости» — на устойчивом потоке свопа NVMe выигрывает, и автор это честно пишет. Реальный выигрыш — там, где обращения редкие и одиночные: латентность в 27 раз ниже ощущается именно на спорадических page fault, а не на массовой подкачке. Сценарий, в который это бьёт точно: ноутбук с распаянной памятью, без апгрейда, с простаивающим дискретным GPU. Для всех остальных это, как сформулировал тред, любопытный хак и аргумент в пользу того, что управление VRAM как ресурсом стоило бы поднять на уровень ядра.