Le unità SSD NVMe di ultima generazione sono bestie da milioni di operazioni al secondo, eppure il kernel Linux non riesce sempre a spremerne tutto il potenziale. È un tema che gli sviluppatori conoscono bene e che è tornato prepotentemente in scena durante il summit LSFMM (Linux Storage, Filesystem, Memory Management & BPF) tenutosi in Croazia. Il punto è semplice da capire, anche se la soluzione non lo è affatto: tra lo spazio utente, il block layer e il driver PCIe, una fetta di prestazioni si disperde in operazioni intermedie come allocazioni, mapping DMA e sincronizzazioni interne. I dispositivi PCIe 5.0 più recenti offrono throughput che fino a poco tempo fa sembravano fantascienza, ma il software spesso non tiene il passo.
Ed è qui che entra in gioco Jens Axboe, storico responsabile del sottosistema block I/O di Linux e creatore di iouring, l’interfaccia del kernel pensata per migliorare le prestazioni delle operazioni I/O asincrone. Axboe ha pubblicato una serie di patch sperimentali che puntano a tagliare parte di quel costo computazionale. I primi benchmark parlano di un incremento di circa il 60% nelle prestazioni I/O per singolo core CPU. Un numero che fa alzare più di un sopracciglio, soprattutto considerando che il lavoro va a toccare meccanismi interni piuttosto profondi del kernel Linux.
SPDK, iouring e la corsa a ridurre l’overhead dello storage
La discussione ha un peso molto concreto per chi lavora con database, storage distribuito, motori di virtualizzazione e piattaforme di intelligenza artificiale. Il collo di bottiglia, ormai, non si trova quasi mai nel disco fisico: emerge nel software che orchestra le richieste.
SPDK (Storage Performance Development Kit) rappresenta da tempo l’alternativa radicale: spostare la gestione I/O nello spazio utente, dialogando quasi direttamente con il controller NVMe. I vantaggi sono evidenti, meno cambi di contesto, meno chiamate di sistema, latenze molto più basse. Ma SPDK richiede configurazioni dedicate, isolamento dei dispositivi e spesso applicazioni scritte su misura. Non è qualcosa che si butta dentro un server qualsiasi e funziona.
Linux, dal canto suo, deve mantenere compatibilità, supporto multiutente, page cache, scheduling e sicurezza. E proprio al summit LSFMM la domanda era questa: quanto margine può ancora recuperare il kernel senza rinunciare ai vantaggi che lo rendono il sistema operativo di riferimento per i server?
Quando Axboe introdusse iouring nel kernel Linux 5.1, l’obiettivo era superare i limiti delle vecchie interfacce. Il sistema si basa su due ring buffer condivisi tra spazio utente e kernel: Submission Queue e Completion Queue. L’applicazione prepara le richieste I/O in memoria condivisa e il kernel le elabora riducendo al minimo le syscall necessarie. Database come PostgreSQL hanno già sperimentato integrazioni specifiche, e diverse piattaforme cloud native stanno investendo parecchio su questa interfaccia.
Il nuovo lavoro di Axboe, identificato come iouring io slots, introduce un’estensione del meccanismo dei registered buffers. Ogni buffer registrato può ora avere associata una struttura già pronta e preconfigurata. La mappatura DMA, quel processo con cui il sistema operativo prepara le aree di memoria accessibili direttamente dalle periferiche senza coinvolgere continuamente il processore, viene effettuata in anticipo invece che nel momento più critico della gestione della richiesta. Nei workload NVMe ad alta concorrenza, risparmiare anche poche centinaia di nanosecondi per operazione può tradursi in incrementi enormi sul throughput totale per ciascun core.
Perché quel 60% in più va letto con attenzione
Le patch non riguardano solo iouring: Axboe ha messo mano anche al codice del sottosistema block e al driver NVMe PCIe. Ottimizzare soltanto l’interfaccia utente avrebbe prodotto benefici limitati se il resto dello stack avesse continuato a introdurre latenze.
I numeri pubblicati sono interessanti ma richiedono una lettura attenta. L’incremento del 60% riguarda le prestazioni per singolo core e nasce da benchmark molto specifici, focalizzati su workload storage altamente ottimizzati. Non significa che qualsiasi server Linux otterrà automaticamente lo stesso miglioramento: molto dipende dal tipo di applicazione, dal pattern I/O, dal file system utilizzato e persino dalla topologia NUMA della macchina.
C’è poi un aspetto che gli amministratori di sistema non possono ignorare: iouring ha aumentato sensibilmente la superficie d’attacco del kernel. Google ha dichiarato che una quota molto elevata degli exploit kernel nel proprio programma bug bounty del 2022 coinvolgeva vulnerabilità legate proprio a io_uring. Non a caso, piattaforme come ChromeOS, Android e alcuni profili seccomp containerizzati hanno introdotto restrizioni specifiche sulle syscall collegate. Le nuove ottimizzazioni proposte da Axboe aggiungono ulteriore complessità interna, il che non le rende necessariamente insicure ma fa pensare che la fase di review sarà probabilmente molto rigorosa.
