L’intervento tocca i meccanismi di I/O del sottosistema e punta a ridurre la latenza nelle operazioni di lettura e scrittura. La novità interessa soprattutto chi sviluppa su Windows 11 usando distribuzioni Linux virtualizzate, tra directory condivise, container e strumenti di compilazione. Un uso quotidiano, molto concreto.
File condivisi tra Windows e Linux, il vero collo di bottiglia
Il punto delicato di WSL 2 è noto da tempo: il passaggio dei dati tra il file system di Windows e l’ambiente Linux, eseguito dentro una macchina virtuale leggera basata su Hyper-V. Quando un’applicazione Linux legge un file salvato in una cartella Windows, o scrive migliaia di piccoli file durante una build, la richiesta non segue un percorso semplice. Passa attraverso livelli di virtualizzazione, dispositivi VirtIO, memoria condivisa e sistemi di accesso diretto ai dati. È lì che nasce il rallentamento.
A volte quasi invisibile, altre volte abbastanza pesante da farsi sentire nei progetti più grandi. Chi usa WSL per sviluppo software, repository Git molto estesi o ambienti Node.js pieni di dipendenze lo sa bene: la compatibilità è alta, ma l’I/O resta il punto sensibile. Microsoft, negli anni, ha già cambiato più volte strada: prima DrvFs, poi il protocollo Plan 9, quindi il passaggio graduale a virtiofs per rendere più diretto lo scambio di directory tra host e macchina virtuale.
Virtiofs e pool SWIOTLB dedicati: la novità in WSL 2
La modifica più recente riguarda SWIOTLB, cioè Software Input/Output Translation Lookaside Buffer, un componente del kernel Linux usato nelle operazioni DMA, il trasferimento diretto dei dati tra memoria e dispositivi. In un sistema virtualizzato come WSL 2, alcuni dispositivi VirtIO usano buffer intermedi gestiti da SWIOTLB per mantenere stabile e compatibile l’accesso alla memoria. Il sistema funziona, ma aveva un limite pratico: più dispositivi potevano ritrovarsi a usare lo stesso pool temporaneo.
Quando le richieste arrivano insieme, nasce la contesa. Lock, attese, piccoli ritardi che, sommati, pesano. La patch inserita dagli sviluppatori Microsoft cambia proprio questo punto: ogni dispositivo VirtIO può usare un pool SWIOTLB dedicato, invece di dipendere da una risorsa comune. In parole semplici, le richieste di virtiofs per l’accesso ai file condivisi non devono più contendersi le stesse strutture usate da altri dispositivi virtualizzati.
Meno traffico nello stesso snodo, meno latenza. Il vantaggio riguarda soprattutto virtiofs, già usato in diversi sistemi di virtualizzazione per condividere cartelle tra host e guest con prestazioni migliori rispetto a soluzioni più vecchie. In WSL 2, Microsoft lo sta spingendo per ridurre il peso del vecchio schema basato su Plan 9 e socket Hyper-V. Una modifica piccola da leggere, ma concreta negli effetti.
Come attivare l’ottimizzazione e quali requisiti servono
La nuova gestione dei pool SWIOTLB è disponibile nelle versioni più recenti del kernel usato da WSL 2. Per provarla, secondo le indicazioni tecniche del progetto pubblico Microsoft, si può aggiornare il sottosistema da PowerShell o dal Prompt dei comandi aperti come amministratore, usando wsl.exe --update --pre-release. Si tratta però di una versione preliminare: meglio considerarla adatta a sviluppatori, amministratori e utenti che sanno cosa stanno facendo.
Per ottenere davvero il miglioramento bisogna anche abilitare virtiofs. L’opzione va inserita nel file .wslconfig, nella cartella del profilo utente Windows, aggiungendo le righe [wsl2] e virtiofs=true. Poi serve arrestare WSL con wsl --shutdown e riaprire la distribuzione Linux. Un passaggio rapido, ma indispensabile. C’è infine il tema della memoria: Microsoft indica almeno 64 MB liberi per il pool SWIOTLB dedicato. Nella pratica, conviene assegnare alla macchina WSL 2 almeno 1 GB di RAM, soprattutto se si usano compilazioni, container o carichi con molte operazioni di input/output. Senza l’attivazione manuale di virtiofs, WSL continua a usare il sistema precedente basato su Plan 9.
Compilazioni, Docker e AI: dove si vedrà la differenza
L’effetto della modifica dovrebbe emergere soprattutto nei lavori che producono molte operazioni sul file system. Una compilazione C++ con migliaia di file, una build JavaScript con una directory node_modules molto grande, oppure immagini Docker montate e ricostruite più volte durante la giornata: sono casi in cui pochi millisecondi per operazione possono diventare minuti persi. Non significa arrivare alle prestazioni di un Linux nativo, ma è un passo nella direzione giusta.
La novità si inserisce anche nel percorso più ampio di WSL 2, che Microsoft usa sempre più come ponte tra Windows e ambienti Linux moderni: dai container Docker ai workflow Kubernetes, fino ai carichi di AI e machine learning accelerati da GPU. Anche nel lavoro su strumenti come wslc, runtime pensato per eseguire container Linux in modo più integrato, la velocità di accesso ai dati diventa centrale. File, cache, modelli, dataset: passa tutto da lì. Per chi sviluppa ogni giorno su Windows, non cambia l’interfaccia e non cambiano le abitudini. Cambia quello che sta sotto. E in WSL 2, dove spesso la differenza tra comodità e rallentamento si misura proprio nel file system condiviso, può contare parecchio.
