Linux accelera SSD NVMe: patch promettono fino al 60% di prestazioni I/O in più

Una discussione tecnica durante il summit LSFMM (Linux Storage, Filesystem, Memory Management & BPF) in Croazia ha riacceso un tema che gli sviluppatori Linux conoscono bene: il kernel riesce davvero a sfruttare fino in fondo le unità SSD NVMe moderne oppure parte della “potenza” disponibile si perde ancora lungo il percorso tra userspace, block layer e driver PCIe? I dispositivi PCIe 5.0 più recenti superano infatti ormai milioni di IOPS (Input/Output Operations Per Second) e assicurano throughput (quantità di dati che può essere trasmessa in un dato periodo di tempo) che fino a pochi anni fa sembravano irraggiungibili; il software, però, continua spesso a pagare overhead legati a allocazioni, mapping DMA e sincronizzazioni interne.

Jens Axboe, storico responsabile dello sviluppo del sottosistema Linux dedicato alla gestione delle operazioni di input/output sui dispositivi di archiviazione (block I/O) e creatore di io_uring, interfaccia del kernel progettata per migliorare le prestazioni delle operazioni I/O asincrone, ha pubblicato una serie di patch sperimentali che puntano proprio a ridurre parte di quel costo computazionale. I primi benchmark parlano di un incremento di circa il 60% nelle prestazioni I/O per singolo core CPU. Numeri importanti, specie se si considera che il lavoro modifica direttamente alcuni meccanismi interni del kernel Linux.

Perché SPDK continua a mettere pressione al kernel Linux

La questione portata dinanzi agli occhi degli sviluppatori del kernel Linux ha un peso concreto per database, storage distribuito, motori di virtualizzazione e piattaforme AI.

Basta guardare l’evoluzione dell’hardware: SSD NVMe enterprise capaci di oltre 2 milioni di IOPS e schede di rete da 400 Gbps hanno reso evidente un problema che fino a poco tempo fa passava quasi inosservato. Il collo di bottiglia non sempre si trova nel disco; spesso emerge nel software che orchestra le richieste.

SPDK, cioè Storage Performance Development Kit, nasce con un approccio radicale: spostare gran parte della gestione I/O in userspace eliminando molti passaggi intermedi del kernel. In pratica, il software dialoga quasi direttamente con il controller NVMe.

Il vantaggio è evidente: si riducono i cambi di contesto tra processi, diminuiscono le chiamate di sistema al kernel (syscall) e le latenze diventano molto più basse. Esistono però anche aspetti più complessi da considerare: SPDK richiede configurazioni specifiche, l’isolamento dedicato dei dispositivi di archiviazione e, spesso, applicazioni progettate appositamente per funzionare con questo modello operativo.

Come approccio generale, Linux deve mantenere la massima compatibilità, supporto multiutente, page cache, scheduling, sicurezza e gestione condivisa dell’hardware. Il summit LSFMM ha messo proprio questo aspetto sotto i riflettori: quanto può ancora recuperare il kernel senza rinunciare ai suoi vantaggi storici?

Il ruolo di io_uring nella riduzione dell’overhead e cosa cambia con le nuove patch

Quando Axboe introdusse io_uring nel kernel Linux 5.1, l’obiettivo era chiaro: superare i limiti dell’ormai vecchia impostazione. Il sistema si basa su due ring buffer condivisi tra userspace e kernel: Submission Queue e Completion Queue. L’applicazione prepara le richieste I/O in memoria condivisa; il kernel le elabora riducendo al minimo le syscall necessarie.

Database ad alte prestazioni, server web e software di caching hanno iniziato rapidamente a sfruttare io_uring: PostgreSQL, ad esempio, ha sperimentato integrazioni specifiche; anche motori storage e piattaforme cloud native stanno investendo molto su questa interfaccia.

Il nuovo lavoro di Axboe (io_uring-io-slots) introduce un’estensione del meccanismo dei registered buffers. Normalmente i buffer registrati permettono di evitare alcune operazioni ripetitive durante le richieste I/O: le nuove patch proposte per il kernel Linux spingono il concetto molto più avanti.

Ogni buffer registrato può ora avere associata una struttura associata già pronta e preconfigurata. Inoltre, la mappatura DMA (processo con cui il sistema operativo prepara e associa le aree di memoria che una periferica può leggere o scrivere direttamente senza coinvolgere continuamente il processore) è effettuata in anticipo invece che durante la fase più critica della gestione della richiesta, riducendo così i ritardi nelle operazioni di accesso diretto alla memoria.

Nei workload NVMe ad alta concorrenza, anche poche centinaia di nanosecondi risparmiate per operazione possono tradursi in incrementi enormi sul throughput totale per ciascun core del processore.

Perché il dato del +60% di prestazioni su Linux va interpretato con cautela

Le patch non riguardano soltanto io_uring: Axboe ha modificato anche il codice del sottosistema block e il driver NVMe PCIe. Il motivo è semplice: ottimizzare soltanto l’interfaccia userspace avrebbe prodotto benefici limitati se il resto dello stack avesse continuato a introdurre latenze.

I numeri pubblicati da Axboe sono interessanti ma richiedono una lettura tecnica attenta. L’incremento riguarda le prestazioni per singolo core e nasce da benchmark molto specifici, focalizzati soprattutto su workload storage altamente ottimizzati.

Non significa automaticamente che qualsiasi server Linux otterrà un miglioramento del 60%: molto dipende dal tipo di applicazione, dal pattern I/O, dal file system usato e persino dalla topologia NUMA della macchina (dove ogni CPU accede più velocemente alla propria memoria locale rispetto a quella collegata ad altri processori).

C’è poi un altro aspetto che gli amministratori di sistema non ignorano: io_uring ha aumentato sensibilmente la superficie d’attacco del kernel Linux. Google ha dichiarato che una quota molto elevata degli exploit kernel nell’ambito del proprio programma bug bounty del 2022 coinvolgeva vulnerabilità legate proprio a io_uring.

Non sorprende quindi che alcune piattaforme abbiano limitato o disabilitato le syscall collegate. ChromeOS, Android e alcuni profili seccomp containerizzati hanno introdotto restrizioni specifiche.

Le nuove ottimizzazioni proposte da Axboe aggiungono ulteriore complessità interna: non significa che siano interventi insicuri ma piuttosto che la fase di review sarà probabilmente molto severa.