La VRAM inutilizzata delle schede grafiche NVIDIA può trasformarsi in qualcosa di insolito ma sorprendentemente utile: uno spazio di swap a disposizione del sistema Linux. L’idea nasce da un’osservazione semplice, quasi banale a pensarci. Tanti notebook, soprattutto i modelli più sottili, montano moduli RAM saldati direttamente sulla scheda madre. Niente espansioni, niente upgrade futuri. E nel frattempo, dentro lo stesso portatile, una GPU NVIDIA dedicata resta accesa a girare a vuoto per gran parte della giornata, mentre si lavora su fogli di calcolo, si scrive codice o si naviga tra una scheda e l’altra del browser.
In quei momenti diversi gigabyte di memoria video se ne stanno lì, inattivi. Il sistema operativo, intanto, quando esaurisce la RAM principale, si appoggia allo swap su SSD. Da questo cortocircuito è nato nbd-vram, un progetto open source che prende una porzione della memoria video e la mette al servizio del kernel come area di scambio. Non è un sostituto della memoria fisica, sia chiaro. È più un modo per smorzare gli effetti peggiori della pressione sulla RAM quando le cose si fanno pesanti. I primi test pubblicati dall’autore parlano di una configurazione con GPU RTX 3070 su laptop, 8 GB di VRAM e 16 GB di RAM. Sommando tutto, RAM, VRAM, zram e swap su SSD, si arriva a circa 46 GB di memoria indirizzabile. Numeri interessanti, anche se vanno presi per quello che sono.
Come funziona, senza moduli kernel da ricompilare
Il bello di nbd-vram è che non reinventa nulla. Poggia su due mattoni già collaudati: il sottosistema NBD (Network Block Device) del kernel Linux e le API CUDA dei driver NVIDIA. L’autore ha scelto un approccio completamente user space, evitando di creare un modulo dedicato.
In pratica un piccolo daemon riserva una fetta di memoria video tramite la libreria libcuda, poi la espone come dispositivo a blocchi usando il protocollo NBD attraverso un socket Unix locale. Dal punto di vista del kernel il risultato sembra un normale dispositivo /dev/nbdX, sul quale si crea tranquillamente una partizione swap. Il percorso dei dati è lineare: il kernel sposta le pagine verso il dispositivo NBD, il driver inoltra le richieste al daemon, e queste vengono tradotte in chiamate CUDA come cuMemcpyHtoD e cuMemcpyDtoH, che fanno la spola tra RAM e VRAM. Il vantaggio pratico non è da poco. Niente moduli kernel da ricompilare dopo ogni aggiornamento, niente aggancio a simboli interni dei driver, che tra una release e l’altra cambiano spesso.
Prestazioni: dove la VRAM fa davvero la differenza
Qui arriva la parte più curiosa. Sul throughput sequenziale un SSD NVMe PCIe 4.0 resta avanti: circa 2,7 GB/s in scrittura e 2,9 GB/s in lettura, contro 1,1 GB/s e 2,3 GB/s della soluzione su VRAM. Anche sugli IOPS casuali a blocchi da 4 KB l’NVMe tiene il passo meglio, perché il percorso NBD/CUDA aggiunge passaggi software che caricano la CPU e frenano il parallelismo.
Ma c’è un però. Lo swap, durante l’uso normale di un notebook, raramente si comporta come un flusso continuo di gigabyte al secondo. Il kernel recupera spesso singole pagine da 4 KB, in modo sporadico. E lì conta la latenza, non la banda. I risultati pubblicati mostrano una differenza notevole: con richieste isolate da 4 KB la VRAM tocca latenze medie intorno ai 335 microsecondi, mentre l’unità NVMe supera spesso i 9 millisecondi. Colpa delle politiche di risparmio energetico come APST, che mandano in sospensione l’SSD tra una richiesta e l’altra. Quando il sistema deve ripescare ogni tanto qualche pagina spostata nello swap, insomma, la memoria video può rivelarsi più pronta di quanto i benchmark classici lascerebbero immaginare.
Requisiti, configurazione e qualche limite
Per far girare il tutto serve una GPU NVIDIA compatibile con CUDA, la libreria libcuda.so.1 e un kernel Linux con il modulo NBD, presente dalla versione 3.0 in avanti. Non occorre il toolkit CUDA completo, e questo semplifica parecchio la distribuzione. Una volta installato, il servizio systemd consente di stabilire quanta VRAM riservare e con quale priorità. L’algoritmo è prudente: prova ad allocare la quantità richiesta e, se non basta, scende a gradini da 512 MB fino a trovare un valore che regge.
C’è anche un occhio di riguardo per i portatili. Quando il sistema passa alla batteria, il servizio può fermarsi da solo per evitare di tenere accesa la GPU senza motivo, salvando autonomia. Resta qualche aspetto da pesare. La VRAM è volatile: tutto sparisce allo spegnimento, esattamente come la RAM, cosa irrilevante per uno swap ma utile da sapere. Poi c’è il consumo: tenere viva una GPU discreta solo per ospitare qualche pagina di swap non conviene su ogni sistema, e alcune GPU mobili fanno lievitare i consumi quando restano sempre attive. Infine l’affidabilità: l’intera catena dipende da un processo user space, e se il daemon dovesse bloccarsi mentre il kernel sta usando attivamente lo swap, potrebbero arrivare stalli o instabilità. Non è un difetto solo di nbd-vram, è il rovescio della medaglia di molte soluzioni a blocchi gestite da processi esterni.