Linux 7.4 accelera l'apertura dei file fino al 39% con una piccola modifica

Una modifica apparentemente piccola al kernel Linux potrebbe produrre un guadagno notevole in uno dei percorsi più comuni del sistema operativo: l’apertura di un file in lettura.

Il lavoro riguarda do_open(), una funzione del Virtual File System coinvolta nella risoluzione dei percorsi e nella creazione del riferimento al file. Lo sviluppatore Mateusz Guzik ha individuato alcune operazioni ridondanti nella gestione della directory entry finale e ha proposto di eliminarle.

La patch è destinata al ciclo di sviluppo di Linux 7.4 ed è già stata inserita nel ramo del sottosistema VFS dedicato alle modifiche di ricerca. I test pubblicati da Phoronix mostrano un incremento rilevante delle operazioni al secondo in uno scenario altamente concorrente, anche se il risultato non rappresenta un’accelerazione generalizzata di ogni carico Linux.

La patch elimina riferimenti duplicati nel VFS

Il percorso interessato comincia dalla risoluzione del nome del file. Il VFS deve associare ogni componente del percorso alla struttura interna chiamata dentry, che collega il nome dell’oggetto alla relativa informazione del filesystem. Secondo la descrizione della patch, il riferimento alla dentry terminale viene acquisito in __legitimize_path(), mentre do_dentry_open() ne acquisisce successivamente un altro. Il primo riferimento viene poi rilasciato in terminate_walk(). La modifica permette a do_dentry_open() di consumare direttamente quello già disponibile, evitando due operazioni sul conteggio dei riferimenti.

Il lavoro non nasce da una revisione improvvisa. Guzik lo ha sviluppato attraverso cinque revisioni nell’arco di oltre due anni, segno della cautela necessaria quando si interviene in una parte centrale del kernel. La patch è composta da circa tre dozzine di righe e non cambia l’interfaccia delle applicazioni. Il vantaggio deriva esclusivamente dalla rimozione di attività interne non necessarie durante l’apertura del file. La differenza è importante perché il miglioramento non dipende da un nuovo filesystem o da una modifica al dispositivo di archiviazione: riguarda il lavoro eseguito dal kernel prima che l’applicazione possa accedere all’oggetto richiesto.

Il benchmark citato da Phoronix è stato eseguito su una macchina virtuale con 20 core, utilizzando il test will-it-scale per aprire ripetutamente lo stesso file in modalità di sola lettura. In questa configurazione, le operazioni al secondo sono aumentate del 39%. Il dato descrive quindi uno scenario specifico e non può essere interpretato come un incremento equivalente delle prestazioni complessive del sistema. Il beneficio dipende dalla quantità di aperture effettuate dal carico di lavoro e dalla concorrenza con cui queste operazioni vengono eseguite.

Linux 7.4 potrebbe includere l’ottimizzazione

La patch è stata inserita nel ramo vfs-7.4.lookup di VFS.git ed è indicata come materiale destinato a Linux 7.4. L’inserimento in un ramo del sottosistema non equivale ancora alla presenza garantita nella versione finale: il codice deve superare la revisione e arrivare alla successiva fase di integrazione del kernel. Phoronix riferisce che l’obiettivo è avere il miglioramento in un kernel stabile entro la fine del 2026.

Il caso evidenzia quanto le prestazioni possano dipendere da dettagli difficili da percepire nell’uso quotidiano. Una singola modifica al conteggio dei riferimenti può sembrare irrilevante quando viene considerata isolatamente, ma il suo costo cambia quando la stessa sequenza viene eseguita continuamente da numerosi processi. Il valore dell’intervento risiede quindi nella riduzione del lavoro ripetitivo in un punto comune del percorso VFS, senza introdurre una nuova API o richiedere modifiche alle applicazioni.

Per gli utenti, l’effetto concreto dipenderà dal tipo di attività svolta e dall’eventuale integrazione della patch nel kernel stabile. I carichi che aprono frequentemente file in lettura sono quelli nei quali l’ottimizzazione ha maggiori possibilità di emergere, mentre applicazioni dominate da calcoli o trasferimenti di grandi quantità di dati potrebbero mostrare differenze molto più contenute. È un esempio di ottimizzazione a basso livello in cui il valore non deriva dalla quantità di codice modificato, ma dalla posizione precisa del lavoro eliminato.