La VRAM inutilizzata delle GPU NVIDIA diventa memoria swap su Linux

La quantità di memoria installata nei notebook rappresenta spesso un limite difficile da aggirare. Molti modelli sottili e leggeri adottano infatti moduli RAM saldati sulla scheda madre, eliminando qualsiasi possibilità di espansione futura. Allo stesso tempo, numerosi sistemi con grafica ibrida integrano una GPU NVIDIA dedicata che resta inattiva per gran parte della giornata, soprattutto durante attività d’ufficio, sviluppo software e navigazione web. In queste situazioni diversi gigabyte di VRAM rimangono inutilizzati mentre il sistema operativo ricorre allo swap su SSD quando la memoria principale si esaurisce.

Da questa osservazione nasce nbd-vram, un promettente progetto open source che trasforma parte della memoria video NVIDIA in uno spazio di swap utilizzabile dal sistema Linux. L’idea appare insolita ma poggia su meccanismi già presenti nel kernel e nei driver CUDA.

I primi test pubblicati dall’autore mostrano una configurazione basata su GPU RTX 3070 su laptop con 8 GB di VRAM e 16 GB di RAM, capace di raggiungere circa 46 GB di memoria complessivamente indirizzabile sommando RAM, VRAM, zram e swap su SSD. Non si tratta di un sostituto della memoria fisica, ma di una soluzione che punta a ridurre gli effetti più evidenti della “pressione” sulla RAM.

Una soluzione che sfrutta tecnologie già presenti nel kernel Linux

Come accennato in precedenza, il nbd-vram fa perno su due componenti consolidati: il sottosistema NBD (Network Block Device) del kernel Linux e le API CUDA offerte dai driver NVIDIA. Invece di creare un modulo kernel dedicato, l’autore ha scelto un approccio completamente user space.

Un piccolo daemon riserva una porzione della memoria video attraverso la libreria libcuda; successivamente espone tale area come dispositivo a blocchi utilizzando il protocollo NBD tramite un socket Unix locale. Dal punto di vista del kernel, il risultato finale appare come un normale dispositivo /dev/nbdX sul quale è possibile creare una partizione swap tradizionale.

Il percorso dei dati è relativamente lineare: il kernel trasferisce le pagine verso il dispositivo NBD, il driver nbd inoltra le richieste al daemon, quindi le operazioni di lettura e scrittura sono tradotte in chiamate CUDA come cuMemcpyHtoD e cuMemcpyDtoH, che spostano i dati tra RAM e VRAM.

La scelta offre un vantaggio pratico non trascurabile. Non esistono moduli kernel da ricompilare dopo un aggiornamento del sistema e non serve agganciarsi a simboli interni dei driver NVIDIA, spesso soggetti a modifiche tra una release e l’altra.

Prestazioni reali: quando la VRAM aiuta davvero

La parte più interessante riguarda i benchmark pubblicati insieme al progetto. A livello di throughput sequenziale, uno storage NVMe PCIe 4.0 continua a mantenere un vantaggio significativo. I test mostrano circa 2,7 GB/s in scrittura e 2,9 GB/s in lettura per il dispositivo NVMe, contro rispettivamente 1,1 GB/s e 2,3 GB/s ottenuti dalla soluzione basata su VRAM.

Anche nelle prove di IOPS casuali a blocchi da 4 KB il supporto NVMe conserva prestazioni superiori: il motivo è che il percorso NBD/CUDA introduce passaggi software che limitano il parallelismo delle richieste e aumentano il carico sulla CPU. Lo swap, tuttavia, raramente opera come un flusso continuo di gigabyte al secondo: durante il normale utilizzo di un notebook, il kernel recupera spesso singole pagine da 4 KB in modo sporadico. In questo scenario la latenza diventa più importante della banda passante.

I risultati pubblicati mostrano una differenza sorprendente. Con richieste isolate da 4 KB, la VRAM raggiunge latenze medie dell’ordine di 335 microsecondi, mentre l’unità NVMe supera frequentemente i 9 millisecondi a causa delle politiche di risparmio energetico come APST (Autonomous Power State Transitions), che pongono l’unità nello stato di sospensione tra una richiesta e l’altra.

Quando il sistema deve recuperare occasionalmente pagine di memoria spostate nello swap, la soluzione basata su VRAM può risultare più reattiva di quanto ci si aspetterebbe osservando soltanto i benchmark tradizionali.

Requisiti e configurazione operativa

Il software richiede una GPU NVIDIA compatibile con CUDA, la presenza della libreria libcuda.so.1 e un kernel Linux dotato del modulo NBD, disponibile dalla versione 3.0 in avanti. Non serve installare il toolkit CUDA completo, dettaglio che semplifica notevolmente la distribuzione del software.

Una volta installato, seguendo le indicazioni riportate nel repository ufficiale, il servizio systemd permette di definire la quantità massima di VRAM da riservare e la priorità dello swap. L’algoritmo adotta un comportamento prudente: tenta inizialmente di allocare la dimensione richiesta e, se la memoria video disponibile non basta, riduce progressivamente la richiesta con decrementi da 512 MB fino a trovare un valore compatibile.

L’autore ha inoltre previsto una modalità di gestione energetica particolarmente utile sui portatili: quando il sistema passa all’alimentazione a batteria, il servizio può arrestarsi automaticamente per evitare che la GPU dedicata resti attiva inutilmente, riducendo così l’autonomia complessiva del notebook.

Limiti tecnici e aspetti da considerare

La VRAM rimane una memoria volatile: qualsiasi contenuto viene perso allo spegnimento del sistema, esattamente come accade con la RAM tradizionale. Per uno spazio da usare come swap non costituisce ovviamente un problema, ma è un elemento importante da tenere presente.

Esiste poi il tema del consumo energetico. Mantenere attiva una GPU discreta esclusivamente per ospitare alcune pagine di swap potrebbe non essere conveniente su tutti i sistemi: alcuni utenti Linux hanno già evidenziato come determinate GPU mobili possano aumentare sensibilmente il consumo quando restano in funzione stabilmente.

Un’altra osservazione riguarda l’affidabilità. L’intera catena dipende da un processo user space che gestisce le richieste NBD: se il daemon dovesse arrestarsi in modo anomalo mentre il kernel utilizza attivamente lo spazio swap, potrebbero verificarsi condizioni di stallo o problemi di stabilità. Non è una criticità esclusiva di nbd-vram, ma una caratteristica comune a molte implementazioni basate su dispositivi a blocchi gestiti da processi esterni.

La soluzione sfrutta componenti maturi del kernel Linux, evita dipendenze da interfacce proprietarie poco accessibili sulle GPU consumer e dimostra come la VRAM possa assumere un ruolo diverso da quello tradizionale. Il risultato finale non rende il sistema più veloce della RAM, naturalmente; offre però un livello intermedio tra memoria principale e SSD che, in alcune circostanze, può ridurre rallentamenti e rendere più gestibili i picchi di utilizzo della memoria.