Nel silenzio del codice sorgente, una trentina di righe modificate nel cuore del kernel Linux promettono di alleggerire un gesto compiuto miliardi di volte al giorno: aprire un file. Lo sviluppatore Mateusz Guzik ha impiegato oltre due anni e cinque revisioni per eliminare operazioni ridondanti nella funzione doopen() del Virtual File System, ottenendo nei test un aumento del 39% nelle aperture per secondo in scenari ad alta concorrenza. È il promemoria che il progresso tecnico non nasce sempre dall'invenzione, ma spesso dalla paziente rimozione di ciò che non avrebbe mai dovuto esserci.
Linux 7.4 accelera l'apertura file del 39% con una patch minuscola al VFS
Lavoro inutile tolto di mezzo, niente di più.
Mark
Perché una modifica così piccola produce un guadagno così grande?
Mimi
Perché l'operazione che ottimizza è una delle più ripetute nel sistema. Quando decine di processi aprono file contemporaneamente, anche una singola operazione ridondante si moltiplica enormemente.
Luke
Ma il 39% è specifico per quel test. Su una macchina virtuale con 20 core che apre lo stesso file in lettura. Non è detto che un utente normale veda quel guadagno.
Mark
Allora quando lo noterà davvero?
Mimi
Quando il carico di lavoro apre file continuamente. Un server web che serve pagine statiche, un database che legge indici, un'applicazione che carica configurazioni di frequente.
Luke
Esatto. Ma se stai facendo calcoli pesanti o trasferendo grandi file, la patch non cambierà quasi nulla.
Mark
Quanto tempo ha impiegato Guzik a sviluppare questa patch?
Mimi
Oltre due anni, con cinque revisioni. Non è stato un lampo di genio. È stato lavoro metodico su una zona critica del kernel.
Luke
Che è il punto: quando tocchi il VFS, devi essere sicuro. Una modifica sbagliata lì dentro può rompere tutto. Per questo ci sono voluti due anni.
Mark
Quando arriverà nei sistemi stabili?
Mimi
L'obiettivo è la fine del 2026. Ma è già nel ramo vfs-7.4.lookup, quindi il percorso è tracciato.
Luke
Però non è ancora nel kernel stabile. Deve ancora superare la revisione completa e l'integrazione. Dire che arriverà entro fine anno è un'intenzione, non una certezza.
O Pulso
- Ogni volta che un processo apre un file, il kernel Linux compiva in silenzio due operazioni sul conteggio dei riferimenti dove ne bastava una sola — un'inefficienza invisibile ma costante.
- In ambienti ad alta concorrenza, quella ridondanza si moltiplicava per decine di processi simultanei, trasformando un piccolo spreco in un collo di bottiglia misurabile.
- Guzik ha proposto una correzione chirurgica: permettere a dodentryopen() di riutilizzare il riferimento già acquisito, eliminando il passaggio superfluo senza toccare alcuna API esterna.
- I benchmark su macchina virtuale a 20 core mostrano un +39% nelle operazioni di apertura file al secondo, un risultato che però dipende fortemente dal tipo di carico di lavoro.
- Il codice è nel ramo vfs-7.4.lookup ma deve ancora superare la revisione finale; l'arrivo in un kernel stabile è atteso entro la fine del 2026.
Nel silenzio del codice sorgente, una trentina di righe modificate nel cuore del kernel Linux promettono di alleggerire un gesto compiuto miliardi di volte al giorno: aprire un file. Lo sviluppatore Mateusz Guzik ha impiegato oltre due anni e cinque revisioni per eliminare operazioni ridondanti nella funzione doopen() del Virtual File System, ottenendo nei test un aumento del 39% nelle aperture per secondo in scenari ad alta concorrenza. È il promemoria che il progresso tecnico non nasce sempre dall'invenzione, ma spesso dalla paziente rimozione di ciò che non avrebbe mai dovuto esserci.
Una modifica di poche decine di righe al kernel Linux sta per rendere più veloce una delle operazioni più comuni che un sistema operativo compie: aprire un file in lettura. Con Linux 7.4, i test registrano un aumento del 39% nel numero di aperture al secondo in scenari ad alta concorrenza. Non si tratta di nuovo hardware né di un filesystem rivoluzionario, ma semplicemente di lavoro inutile eliminato.
La patch interviene su doopen(), funzione del Virtual File System che entra in gioco quando il kernel risolve un percorso e crea il collegamento al file. Mateusz Guzik ha individuato un'inefficienza precisa: il riferimento alla directory entry finale veniva acquisito in __legitimize_path(), poi dodentryopen() ne acquisiva un secondo, e il primo veniva rilasciato solo in terminate_walk(). Due operazioni sul conteggio dei riferimenti eseguite senza alcuna necessità. La correzione consente a dodentryopen() di usare direttamente il riferimento già disponibile.
Non è stata un'intuizione rapida: Guzik ha affinato la patch attraverso cinque revisioni in oltre due anni, una prudenza comprensibile quando si interviene in una zona così critica del kernel. Il risultato finale non altera in alcun modo le API visibili alle applicazioni e non richiede nulla agli sviluppatori di software.
Il benchmark è stato condotto su una macchina virtuale con 20 core, aprendo ripetutamente lo stesso file in sola lettura. Il +39% descrive quella configurazione specifica e non va letto come un miglioramento generale del sistema: il beneficio sarà massimo per i carichi che aprono continuamente file in lettura, quasi impercettibile per applicazioni dominate da calcoli intensivi o trasferimenti di grandi volumi di dati.
Il codice si trova già nel ramo vfs-7.4.lookup del sottosistema VFS, ma deve ancora superare la revisione e la fase di integrazione. L'obiettivo è includerlo in un kernel stabile entro la fine del 2026. Questo caso ricorda come le prestazioni dipendano spesso da dettagli invisibili nell'uso quotidiano: una singola operazione ridondante sembra trascurabile, ma ripetuta all'infinito da decine di processi contemporanei diventa un peso reale.
Una modifica di poche decine di righe al cuore del kernel Linux sta per portare un miglioramento misurabile a una delle operazioni più elementari e più frequenti che un sistema operativo compie: aprire un file in lettura. Con Linux 7.4, i test mostrano un aumento del 39% nel numero di operazioni al secondo in scenari ad alta concorrenza. Non si tratta di nuovo hardware, non di un filesystem rivoluzionario, ma semplicemente di lavoro inutile eliminato.
La patch tocca doopen(), una funzione del Virtual File System che interviene quando il kernel deve risolvere un percorso e creare il collegamento al file. Lo sviluppatore Mateusz Guzik ha individuato un'inefficienza nella gestione della directory entry finale: il sistema stava ripetendo operazioni senza alcuna ragione pratica. La soluzione è stata proporre di eliminarle. Il codice è già stato inserito nel ramo vfs-7.4.lookup del sottosistema VFS, in preparazione del ciclo di sviluppo della nuova versione.
Per capire cosa accade realmente, bisogna seguire il percorso di risoluzione del nome. Quando il VFS deve aprire un file, collega ogni componente del percorso a una struttura interna chiamata dentry, che funge da ponte tra il nome dell'oggetto e i dati del filesystem. Secondo la descrizione della patch, il riferimento alla dentry finale veniva acquisito in __legitimizepath(), poi dodentryopen() ne acquisiva un secondo, e il primo veniva infine rilasciato in terminatewalk(). In altre parole: due operazioni sul conteggio dei riferimenti eseguite senza motivo. La modifica consente a dodentryopen() di utilizzare direttamente il riferimento già disponibile, eliminando il lavoro ridondante.
Non è stata un'intuizione improvvisa. Guzik ha lavorato sulla patch attraverso cinque revisioni nel corso di oltre due anni, un dato che illustra bene la cautela necessaria quando si interviene su una zona così critica del kernel. Il risultato finale è circa una trentina di righe di codice che non alterano in alcun modo l'interfaccia vista dalle applicazioni. Il vantaggio emerge unicamente dalla rimozione di attività interne superflue durante l'apertura del file, dal lavoro che il kernel svolge prima ancora che il programma possa accedere all'oggetto richiesto.
Il benchmark è stato condotto su una macchina virtuale con 20 core, utilizzando il test will it scale per aprire ripetutamente lo stesso file in sola lettura. In quella configurazione, le operazioni al secondo sono aumentate del 39%. È un numero che descrive una situazione molto specifica e non deve essere interpretato come un aumento generale delle prestazioni del sistema. Il beneficio dipende da quante aperture di file il carico di lavoro effettivamente compie e da quanta concorrenza esiste tra i processi che le eseguono.
La patch è stata marcata come materiale destinato a Linux 7.4, ma trovarsi in un ramo di sottosistema non significa essere già inclusa nella versione finale. Il codice deve ancora superare la revisione e passare attraverso la fase di integrazione successiva. L'obiettivo dichiarato è avere il miglioramento in un kernel stabile entro la fine del 2026.
Questo caso illustra bene come le prestazioni dipendano da dettagli che nell'uso quotidiano rimangono invisibili. Una singola operazione sul conteggio dei riferimenti, considerata isolatamente, sembra insignificante. Ma il calcolo cambia quando la stessa sequenza viene ripetuta all'infinito da decine di processi contemporaneamente. Il valore risiede interamente nella riduzione del lavoro ripetitivo in un punto molto frequentato del percorso VFS, senza introdurre nuove API e senza richiedere nulla agli sviluppatori di applicazioni.
Per chi utilizza il sistema ogni giorno, l'effetto pratico dipenderà dal tipo di attività svolta e dall'effettivo arrivo della patch nel kernel stabile. I carichi che aprono continuamente file in lettura sono quelli dove l'ottimizzazione ha le maggiori possibilità di manifestarsi, mentre le applicazioni dominate da calcoli intensivi o dal trasferimento di grandi volumi di dati vedranno differenze molto più contenute.
Citações Notáveis
Una modifica minuscola al kernel che nei test ha fatto salire del 39% il numero di operazioni al secondo in uno scenario molto affollato— Descrizione della patch nel ramo vfs-7.4.lookup
Quer a matéria completa?
Leia o original em TecnoAndroid ↗