LINUX.ORG.RU

Опубликован NBD-VRAM

 nbd-vram, ,


1

0

Опубликован открытый проект NBD-VRAM, позволяющий задействовать часть видеопамяти NVIDIA GPU как swap-пространство в Linux. Проект ориентирован прежде всего на ноутбуки с распаянной оперативной памятью, где RAM нельзя расширить, но при этом в системе есть дискретная видеокарта NVIDIA RTX/GTX с неиспользуемой VRAM. Код написан на C и shell, распространяется под лицензией MIT.

Идея NBD-VRAM проста: если система уже начинает уходить в swap на SSD, можно поставить перед SSD ещё один промежуточный слой — видеопамять. Автор приводит пример с ноутбуком на RTX 3070 Laptop: из 8 ГБ VRAM было выделено 7 ГБ под swap, а суммарно с RAM, zram и SSD swap система получила около 46 ГБ адресуемой памяти. Предполагаемый порядок переполнения такой: сначала используется RAM, затем VRAM как быстрый swap, затем zram, и только после этого SSD.

Технически NBD-VRAM не добавляет новый драйвер ядра. Небольшой демон выделяет память видеокарты через CUDA Driver API, затем отдаёт её ядру Linux как блочное устройство через NBD — Network Block Device — поверх Unix-сокета. После подключения стандартным nbd-client в системе появляется /dev/nbdX, которое можно разметить как обычный swap через mkswap и включить через swapon.

Автор отдельно подчёркивает, что такой подход выбран из-за ограничений потребительских видеокарт NVIDIA. Более прямой путь через NVIDIA P2P API на GeForce, по его словам, упирается в EINVAL, так как соответствующие возможности фактически доступны только для профессиональных и серверных моделей. Вариант с прямым обращением к BAR1 также не сработал: доступной оказывается только небольшая отображённая область, а чтение из остальной части возвращает нули. NBD-подход обходит это ограничение, так как использует обычные CUDA-копирования cuMemcpyHtoD и cuMemcpyDtoH.

Возможности

  • Использование VRAM как обычного Linux swap. После запуска демон предоставляет видеопамять как /dev/nbd0 или другое NBD-устройство, которое для ядра выглядит как стандартное блочное устройство.

  • Работа без собственного модуля ядра. Проект не требует писать, собирать и сопровождать отдельный kernel module, не использует внутренние символы NVIDIA-драйвера и должен переживать обновления ядра и драйвера без пересборки.

  • Ориентация на потребительские NVIDIA GPU. В требованиях указаны NVIDIA GPU с поддержкой CUDA, включая потребительские RTX/GTX-карты, официальный NVIDIA-драйвер с libcuda.so.1, модуль nbd в ядре Linux, nbd-client, gcc и make. CUDA Toolkit при этом не нужен.

  • systemd-интеграция. Установка через install.sh добавляет сервис vram-swap-nbd, который можно запускать через systemctl; после установки сервис включается для автоматического старта при загрузке.

  • Настройка размера и приоритета swap. В systemd-unit можно задать VRAM_SETUP_SIZE_MB, то есть верхний предел выделяемой VRAM, и VRAM_SWAP_PRIORITY, то есть приоритет swap-устройства. Чем выше приоритет, тем раньше Linux будет использовать этот swap-слой.

  • Автоматическое уменьшение запрошенного размера. Если требуемый объём VRAM недоступен, демон пытается уменьшать размер блоками по 512 МиБ, чтобы всё равно выделить доступный объём, например если часть памяти уже занята композитором или графической сессией.

  • Проверочные сценарии. В репозитории есть test-nbd.sh для смоук-теста с записью/чтением 1 МиБ и test-fill.sh для стресс-проверки всего VRAM-раздела.

  • Заявленная производительность около 1,3 ГБ/с. На RTX 3070 Laptop автор измерил последовательную запись 7 ГБ блоками по 4 МБ примерно на уровне 1,3 ГБ/с.

Сценарии применения

Ноутбуки с распаянной RAM. Главный сценарий — современные ноутбуки, где 16 или 32 ГБ оперативной памяти уже не хватает, но расширить её невозможно. Если в такой машине есть дискретная RTX-карта, часть VRAM можно использовать как дополнительный swap-слой. Это не превращает VRAM в полноценную RAM, но может спасти систему от резкого ухода в медленный SSD swap или от OOM-killer при пиковых нагрузках.

Тяжёлые рабочие окружения разработчика. IDE, браузер с десятками вкладок, Docker-контейнеры, локальные базы данных, сборки больших проектов и тестовые окружения легко создают кратковременные пики потребления памяти. В таком сценарии NBD-VRAM может работать как буфер: не ускорять обычную работу, а смягчать момент, когда RAM закончилась.

Снижение нагрузки на SSD swap. Если swap на SSD используется часто, это не только медленнее, но и создаёт лишнюю запись на накопитель. VRAM-swap можно поставить с более высоким приоритетом, чтобы при переполнении RAM система сначала вытесняла страницы в видеопамять, а уже потом обращалась к SSD. Особенно это актуально для ноутбуков, где SSD тоже часто несъёмный или дорогой в замене.

Комбинация с zram. Автор прямо описывает схему, где VRAM swap получает более высокий приоритет и принимает первый «разлив» памяти, zram используется следующим уровнем, а SSD остаётся последней линией обороны. Такая схема может быть полезна для рабочих станций и ноутбуков, где важнее сохранить отзывчивость системы при нехватке памяти, чем получить максимальную предсказуемость задержек.

Локальные AI/LLM-задачи вокруг GPU, но не вместо VRAM для модели. NBD-VRAM не увеличивает видеопамять, доступную CUDA-приложению как VRAM для модели. Это обратный сценарий: не RAM используется как VRAM, а VRAM используется как swap для обычной памяти Linux. Поэтому проект не позволит напрямую загрузить в GPU модель большего размера. Но он может быть полезен на машине, где рядом с LLM-инференсом работают браузер, IDE, индексаторы, Python-окружения и контейнеры, а системная RAM начинает заканчиваться.

Домашние и экспериментальные рабочие станции. Проект интересен для пользователей, у которых видеокарта часто простаивает вне игр, рендера или ML-задач. Например, 8–12 ГБ VRAM на десктопной GeForce можно временно превратить в дополнительный слой swap для тяжёлых задач компиляции, обработки данных или запуска виртуальных машин.

Ограничения

NBD-VRAM не является заменой оперативной памяти. Доступ к такому swap идёт по цепочке kernel swap → /dev/nbdX → nbd-драйвер → Unix-сокет → демон → CUDA-копирование → VRAM, поэтому задержки и поведение будут отличаться от настоящей RAM. Это скорее аварийный или промежуточный слой между RAM и SSD, чем способ «добавить памяти» без последствий.

Также проект завязан на официальный стек NVIDIA с CUDA. Nouveau/Nova для этого не подходят, так как требуется libcuda.so.1. Phoronix также отмечает, что NBD-VRAM создан именно для потребительских NVIDIA GPU, где альтернативные подходы через NVIDIA P2P API не работают.

В сухом остатке, NBD-VRAM — небольшой, но любопытный системный хак для Linux: он не делает чудес и не заменяет апгрейд RAM, но позволяет использовать простаивающую видеопамять как дополнительную ступень swap перед SSD. Для ноутбуков с распаянной памятью и дискретной RTX-картой это может оказаться практичным способом переживать пиковые нагрузки без немедленного падения приложений или болезненного ухода в медленный накопитель.

>>> Источник

★★★★★

Проверено: cetjs2 ()

прикольно, какие костыли нужны, чтобы просто получить доступ к видеопамяти
что тут, что там

madcore ★★★★★
()

Ну в общем @firkax местами прав. Текст лучше обрезать до заголовка «Возможности». Читать будет легче и проще. А всех интересующихся слать на страницу софтины.

einhander ★★★★★
()
Ответ на: комментарий от Sylvia

У интела вроде была такая настройка. Но я вовремя запихнул 32Гб рамы в ноут и на встройку не обращаю внимание.

einhander ★★★★★
()
Ответ на: комментарий от einhander

у меня 2 ноута с встройками Ryzen *500U

Lenovo , с Raven Ridge (Vega) на котором vramfs, упомянутый выше не работает и вообще на нем сложно что-то завести из разряда аппаратного кодирования видео или OpenCL, жрет 1.5 Gb системной памяти, данное значение не меняется, в настройках BIOS просто нет ничего

Maibenben с Renoir (Vega), в нем в BIOS по умолчанию 512Мб, я поставила 2Гб, т.к. взяла его для того чтобы иметь возможность зайти в игры и «отметиться», как он ведет себя с Linux - не знаю.

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

сложно что-то завести из разряда аппаратного кодирования видео

Я думал подобные проблемы давно миновали карты АМД(

einhander ★★★★★
()
Ответ на: комментарий от einhander

я тоже хотела так думать, но «прилетела птица обломинго»

Sylvia ★★★★★
()

Для eGPU полезно даже не смотря на идиотскую лицензию, но из-за RTX Spark в ближайшие годы потеряет актуальность.

zabbal ★★★★☆
()
Ответ на: комментарий от madcore

а не ты ли в дугой теме затирал, что это ОС должна распоряжаться видимопамятью?

Дело не в этом, а в том что производитель имеет возможность блокировать некоторые настройки компьютера на этапе инициализации.

Если базовая система не поддерживает их инициализацию на старте, то обUMAFься сколько угодно - оно просто не найдет и не покажет этот пункт.

Видимопамять на x86 как по мне - вообще лишняя костылированная сущность из прошлого, когда она была необходима как буфер трансляции между графическим ПО и монитором. Сейчас это разделение лишь мешает: загружая текстуры с носителя, нам приходится сначала загружать их в ОЗУ, затем из ОЗУ копировать в графическую память, а к идее «нахера это делать, если память встроенная» пришли вот только совсем недавно, и то благодаря Аппле.

windows10 ★★★★★
()
Ответ на: комментарий от windows10

Про консоли решил не вспоминать?

У видеопамяти есть абилка высокой ПСП. У системной памяти поточная скорость в разы меньше. Зато латентность получше. Эпл решает это накристальной памятью с широким интерфейсом. В ПК это не особо применимо. Поэтому существует разделение

cobold ★★★★★
()
Последнее исправление: cobold (всего исправлений: 2)
Ответ на: комментарий от windows10

да я так и понял, что тугие разработчики железа пытаются решать какие-то несуществующие проблемы
ынтел ещё ведь при анонсе шины agp и своей легендарной карты i740 объявила, что отдельный видеобуфер больше не нужон

madcore ★★★★★
()
Ответ на: комментарий от windows10

У меня не добавил эту возможность. На другом ноуте с 2500U не добавил. Пока получалось.

Прочти, как это работает.

https://www.reddit.com/r/AMDLaptops/comments/1fjqujx/increasing_vram_with_smo...

Пишут, что в новых биосах на стим деке эту возможность закрывают. Люди пользуются разблокировками какими-то.

Jeronimo ★★★
()
Последнее исправление: Jeronimo (всего исправлений: 1)
Ответ на: комментарий от Jeronimo

Интересный вариант, спасибо, но я решила проблему с другой стороны, просто добила ноутбук памятью до 20 Гб, хотя по спекам там максимум 12 (4 Гб распаяно, 1 планку можно добавить, изначально там было заткнуто еще 4 Гб , (4+4) - 1.4 = 6.6, в статах хоть и пишет что VRAM 1024 Mb, но куда-то еще улетает 400 Мб)

Вообщем уже не важно, не буду мучать ноут экспериментами

Но OpenCL или аппаратное ускорение хоть чего-нибудь (кроме декодирования видео, которое работает) я бы на нем все же хотела завести

Sylvia ★★★★★
()
Последнее исправление: Sylvia (всего исправлений: 1)

Это очень, очень, очень круто. Проверил на ноутбуке i5 + 1050/4Gb. Всё полностью работает. Выделилось 3600мб. Отзывчивость - отличная. Вопрос «Можно ли использовать память видеокарты как оперативную» - решен, в операционной системе линукс точно можно.

bloody_enterprise
()
Ответ на: комментарий от den73

А если нет контроля чётности на карте, тогда что?

Тогда нужно купить карту с контролем чётности!

vasya_pupkin ★★★★★
()
Ответ на: комментарий от windows10

Сейчас это разделение лишь мешает: загружая текстуры с носителя, нам приходится сначала загружать их в ОЗУ, затем из ОЗУ копировать в графическую память

Direct Storage?

vasya_pupkin ★★★★★
()
Последнее исправление: vasya_pupkin (всего исправлений: 1)

Текст читается как выхлоп нейронки.

pihter ★★★★★
()
Ответ на: комментарий от madcore

radeonsi, не хотят, пишут что нет устройств OpenCL 🤷‍♀️

даже ffmpeg с vulkan encoder сегфолтит

Sylvia ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Direct Storage?

Это лишь поменяет место (destination) загрузки, но не избавит от копирования, потому что процессор тоже делает некоторые вычисления с этими данными.

Ну то есть совсем совсем для текстур - поможет.

windows10 ★★★★★
()
Ответ на: комментарий от cobold

Про консоли решил не вспоминать?

Консоли нынче - это недоПК.

У системной памяти поточная скорость в разы меньше.

Это решается многоканальностью.

Эпл решает это накристальной памятью с широким интерфейсом.

Эппл решает это всем сразу, а не одной технологией. На высоких скоростях обмена данных, затыки появляются уже в программных алгоритмах обработки, это и есть причина создания всяких NVMe.

Из линуксячьего мира хрестоматийный пример - велосипед марки «blk-mq».

windows10 ★★★★★
()

Идея очень классная. Особенно в плане отвязки от драйверов через /dev/nbd. Очевидно аналогичный демон можно реализовать через openCL для дискреток АМД и интел, а может быть и для нвидии. В идеале бы ещё в того же демона встроить авторежим слежения за использованием видеопамяти и динамически менять размер свопа...

kirill_rrr ★★★★★
()

Кстати, в 2010-х видеопамять нвидий уже использовали в качестве рам-диска для свопа.

kirill_rrr ★★★★★
()
Ответ на: комментарий от windows10

Консоли нынче - это недоПК.

Очень ценная информация. Тем не менее эти недопк используют единую память. И делать это начали раньше эпла

Это решается многоканальностью.

Конечно решается. Вот возьмём средненькую nvidia rtx 3060. ПСП 360 GB/sec. Два канала на топовом интеле с хорошей ддр5 дают 120GB/sec. То есть чтобы питать одну видяху надо 6 каналов. Ну и ещё 2 на проц. Итого 8. Вот значит нам нужна материнка и сокет с 8 каналами памяти и 8 отдельных модулей памяти. Ну и ещё какую-нибудь скоростную шину между процом и ГПУ чтобы решать вопросы когерентности кэшей. И все это в пекарне

cobold ★★★★★
()
Ответ на: комментарий от Sylvia

во времена LTSP десятки тонких клиентов юзали без проблем, но с тех пор всё могло поломаться...
на замену nbd есть более взрослое решение - iSCSI

madcore ★★★★★
()
Ответ на: комментарий от Sylvia

Это потому что сеть. локально то разрывов и потерь не будет.

kirill_rrr ★★★★★
()
Ответ на: комментарий от cobold

Вот возьмём средненькую nvidia rtx 3060. ПСП 360 GB/sec.

ПСП между чем и чем?

То есть чтобы питать одну видяху надо 6 каналов.

Допустим.

Вот значит нам нужна материнка и сокет с 8 каналами памяти и 8 отдельных модулей памяти.

Нет не нужна.

Это разделение «канал = планка» существует исключительно ради существования дешевых вариантов на рынке. Решения по нескольку каналов на планке существовали и раньше, а сейчас с приходом DDR5 стали дефолтом.

Ну и ещё какую-нибудь скоростную шину между процом и ГПУ чтобы решать вопросы когерентности кэшей

Зачем? Ведь в твоей средненькой nvidia rtx 3060 нет скоростных шин.

windows10 ★★★★★
()

Глубина очереди = 1, размер файла 4 килобайт, скорость чтения 30 мегабайт. При тех же условиях nvme даёт 90 мегабайт. Скорость работы с графической памятью будет на уровне sata 3 ssd. Разница в том, что nvme может быть занят, а видео память всегда свободна, так что, в качестве раздела подкачки подойдёт.

bloody_enterprise
()
Ответ на: комментарий от windows10

Решения по нескольку каналов на планке существовали и раньше, а сейчас с приходом DDR5 стали дефолтом

Ты угараешь? Если один канал на 64 бита разделить на 2 по 32 бита, как сделали в ддр5, то ПСП не увеличивается. Количество линий шины данных не изменилось.

Так что - да, нужна.

Зачем? Ведь в твоей средненькой nvidia rtx 3060 нет скоростных шин.

Мы все ещё обсуждаем общую память между CPU и GPU? В дискретном GPU нет такой шины потому что у нее есть своя выделенная память и с ней он и работает

cobold ★★★★★
()

Кризис цен на оперативную память зашёл уже очень далеко. Уже добрались до памяти видеокарты, чтобы оттуда откусить себе памяти кусок. Следующим шагом будет изъятие неиспользуемой памяти из кеша контроллеров дисков и использование её для расширения оперативки.

Smacker ★★★★★
()

Проверил запись = скорость ssd (что неудивительно, при kernel swap → /dev/nbdX → nbd-драйвер → Unix-сокет → демон → CUDA-копирование → VRAM) В чтении тоже почему-то разницы не заметил (всего в 2 раза быстрее записи), но возможно потому-что у меня 8Tb SSD и он тоже не медленный.

Стабильности нет, оставлял и 1 и 2 гб в запасе на видюхе: Браузер с youtube, docker, запускаешь фильм с vdpau и все, можно вырубиться только по кнопке.

Короче swapfile на ssd рулит пока что.

anonymous_sama ★★★★★
()
Последнее исправление: anonymous_sama (всего исправлений: 2)
Ответ на: комментарий от cobold

Ты угараешь? Если один канал на 64 бита разделить на 2 по 32 бита, как сделали в ддр5, то ПСП не увеличивается.

Конечно же увеличивается. Просто ты прицепился к пропускной способности интерфейса, и забыл про такты. Разделение блоков позволяет обратиться к двум адресам за один такт.

В реальном использовании это дает прирост скорости обмена почти в два раза.

Просто ты видимо не работал вплотную с памятью, а я как назло работал с ней вот прямо сегодня.

- - -

Собственно с этой позиции я и ржу с подобных школьных проектов: своп - это понятная и прозрачная подсистема операционки. Засунуть его в очередное непредназначенное для этого места чтобы получить +8-16 гиг - много ума не надо.

А как насчет такого, ммм? https://ibb.co/s96PsNgr

На всякий случай, если не понятно, уточню: всего лишь «видеокарта» на 768 Гб памяти. Как видишь - полностью видна системой. Пока на SSD, но когда будет больше свободного времени на разборки с ПЛИС - сделаю на елочке из SoDIMM как Gigabyte раньше делали RAMDISK'и.

Мы все ещё обсуждаем общую память между CPU и GPU? В дискретном GPU нет такой шины потому что у нее есть своя выделенная память и с ней он и работает

Шина есть у любой связки «АЛУ - память». Есть она и у видеокарты. Но это все лирика, ты меня устал.

windows10 ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Да туда можно что угодно в общем, оно просто как блочное устройство на /dev/ndb* видно

anonymous_sama ★★★★★
()
Ответ на: комментарий от windows10

Конечно же увеличивается. Просто ты прицепился к пропускной способности интерфейса, и забыл про такты. Разделение блоков позволяет обратиться к двум адресам за один такт.

Конечно же нет. А прицепился к ней я не просто так, а потому что она важна для производительности GPU что в играх, что в ML задачах. А то о чем ты говоришь, это латентность доступа, а не ПСП

cobold ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Оно только как swap работать может, или можно туда типа tmpfs вывалить?

Делаешь:

swapoff /dev/nbd0
mkfs.ext4 /dev/nbd0
mount /dev/nbd0 /mnt

И можно пользоваться как обычным диском.

bloody_enterprise
()
Ответ на: комментарий от den73

А если нет контроля чётности на карте, тогда что?

Разделить память видеокарты на несколько nbd-vram устройств, поднять на них dm-integrity, и объединить в raid-5.

No ★★★
()
Ответ на: комментарий от den73

А если нет контроля чётности на карте, тогда что?

Тогда считать вручную, на бумажке, «в столбик», и записывать результат на бумажке же, химическим карандашом... :))

Somebody ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.