In questo articolo Indice dei contenuti 2 sezioni
Con Linux 7.4 potrebbe arrivare un guadagno di prestazioni piuttosto interessante su una delle operazioni più banali e più ripetute di tutto il sistema operativo, cioè l’apertura di un file in lettura. Il merito va a una modifica minuscola al kernel, roba da poche decine di righe, che nei test ha fatto salire del 39% il numero di operazioni al secondo in uno scenario molto affollato. Niente nuovi filesystem, niente hardware diverso, solo lavoro inutile tolto di mezzo.
La patch riguarda doopen(), una funzione del Virtual File System che entra in gioco quando il kernel deve risolvere un percorso e creare il riferimento al file. Lo sviluppatore Mateusz Guzik ha notato che nella gestione della directory entry finale c’erano operazioni ripetute senza un vero motivo e ha proposto di eliminarle. Il codice è già finito nel ramo del sottosistema VFS dedicato alle modifiche di ricerca, in vista del ciclo di sviluppo della nuova versione.
Cosa fa davvero la modifica al VFS
Il percorso parte dalla risoluzione del nome del file. Il VFS deve collegare ogni componente del percorso a una struttura interna chiamata dentry, che fa da ponte tra il nome dell’oggetto e le informazioni del filesystem. Stando alla descrizione della patch, il riferimento alla dentry terminale viene preso in __legitimizepath(), poi dodentryopen() ne prende un altro, e il primo finisce per essere rilasciato in terminatewalk(). Tradotto: due operazioni sul conteggio dei riferimenti fatte per nulla. La modifica permette a dodentry_open() di usare direttamente quello già disponibile.
Non è stato un lampo di genio improvviso. Guzik ci ha lavorato attraverso cinque revisioni nell’arco di oltre due anni, segno abbastanza eloquente di quanta prudenza serva quando si mette mano a una zona così centrale del kernel. Il risultato sono circa tre dozzine di righe che non toccano in alcun modo l’interfaccia vista dalle applicazioni. Il vantaggio arriva solo dalla rimozione di attività interne superflue durante l’apertura del file, quindi dal lavoro che il kernel svolge prima ancora che il programma possa mettere le mani sull’oggetto richiesto.
Il benchmark è stato eseguito su una macchina virtuale con 20 core, usando il test will it scale per aprire ripetutamente lo stesso file in sola lettura. In quella configurazione le operazioni al secondo sono salite del 39%. Un numero che descrive una situazione ben precisa e non va letto come un aumento generale delle prestazioni del sistema. Il beneficio dipende da quante aperture fa realmente il carico di lavoro e da quanta concorrenza c’è tra i processi che le eseguono.
Quando potrebbe arrivare nel kernel stabile
La patch è stata inserita nel ramo vfs-7.4.lookup di VFS.git ed è marcata come materiale destinato a Linux 7.4. Finire in un ramo di sottosistema però non significa essere già dentro la versione finale, perché il codice deve ancora superare la revisione e passare per la successiva fase di integrazione. L’obiettivo dichiarato è avere il miglioramento in un kernel stabile entro la fine del 2026.
È un caso che racconta bene quanto le prestazioni dipendano da dettagli che nell’uso quotidiano nessuno percepisce. Una singola operazione sul conteggio dei riferimenti presa da sola sembra irrilevante, ma il conto cambia quando la stessa sequenza viene ripetuta all’infinito da decine di processi contemporaneamente. Il valore sta tutto nella riduzione del lavoro ripetitivo in un punto molto frequentato del percorso VFS, senza introdurre nuove API e senza chiedere nulla agli sviluppatori di applicazioni.
Per chi usa il sistema tutti i giorni, l’effetto pratico dipenderà dal tipo di attività svolta e dall’effettivo arrivo della patch nel kernel stabile. I carichi che aprono di continuo file in lettura sono quelli dove l’ottimizzazione ha più possibilità di farsi notare, mentre le applicazioni dominate dai calcoli o dal trasferimento di grandi quantità di dati vedranno differenze molto più contenute.
Fonte: TecnoAndroid
