Linus Torvalds ha affidato il kernel a Claude Code. Il risultato ha sorpreso anche gli scettici

Linus Torvalds ha incaricato l'IA Claude Code di scrivere modifiche per il kernel Linux, ottenendo una triplicazione della velocità di lettura di piccoli blocchi di dati nei test. Otto patch sono state preparate con l'aiuto di Claude Code e le modifiche riguardano la cache di Linux, risolvendo un problema di prestazioni durante la lettura simultanea di piccoli frammenti di un file da parte di più thread.

Linus Torvalds ha incaricato l’IA Claude Code di scrivere modifiche per uno dei sottosistemi più importanti del kernel Linux e ha ottenuto un triplicazione della velocità di lettura di piccoli blocchi di dati nei test. Lo sviluppatore ha apertamente riconosciuto l’autorevolezza della rete neurale, ma ha avvertito che il codice sperimentale non è ancora pronto per essere incluso nel kernel principale.

Il 10 ottobre, il creatore di Linux ha pubblicato un set di modifiche per il sottosistema di gestione della memoria. Otto patch sono state preparate con l’aiuto di Claude Code. Torvalds ha direttamente indicato che l’IA ha scritto il codice, i programmi di test, ha preparato l’analisi dei problemi noti e la prima bozza della descrizione. Lo sviluppatore stesso ha supervisionato il lavoro e ha eseguito le misurazioni sul proprio computer.

Le modifiche riguardano la cache delle pagine di Linux, che memorizza i dati dei file recentemente letti nella memoria operativa per evitare di accedere nuovamente al dispositivo di archiviazione. Gli sviluppatori erano a conoscenza da tempo del problema di prestazioni durante la lettura simultanea di piccoli frammenti di un file da parte di più thread. Il collo di bottiglia si è rivelato non la ricerca delle informazioni e nemmeno la copia dei byte, ma il meccanismo di conteggio degli accessi alle pagine di memoria.

Ad ogni lettura, il kernel incrementa il contatore di riferimenti alla pagina di memoria e, al termine dell’operazione, lo decrementa. Tali azioni aiutano a prevenire il rilascio prematuro della memoria mentre il programma lavora con i dati. Tuttavia, durante gli accessi simultanei da parte di diversi core di elaborazione, le operazioni atomiche sul contatore iniziano a interferire tra loro, poiché i core devono costantemente sincronizzare le modifiche di un’area di memoria.

Torvalds ha scoperto che durante la lettura di 16 byte da un file da parte di otto thread su un laptop con Intel Core i7-8565U, la competizione per il contatore di riferimenti è stata la causa del 99,92% degli eventi registrati di trasferimento di una riga di cache modificata tra i core. La misura si riferisce specificamente agli eventi Load HITM, non alla percentuale del tempo totale di esecuzione del programma. Tuttavia, le misurazioni hanno mostrato quanto sia costosa la sincronizzazione con tale carico di lavoro.

Le patch preparate da Claude Code consentono di leggere i dati senza modificare costantemente il contatore di riferimenti. Invece dello schema precedente, viene utilizzato il meccanismo RCU (Read-Copy-Update), che posticipa il riutilizzo della memoria liberata fino al completamento delle sezioni critiche di lettura. Anche se la pagina è già stata esclusa dalla cache del file, il kernel non rilascerà la memoria corrispondente per altri dati finché il lettore, protetto da RCU, non avrà completato il lavoro.

I risultati si sono rivelati impressionanti. Durante il funzionamento simultaneo di otto thread, le prestazioni sono aumentate da 9,9–10,4 milioni a 30–33 milioni di operazioni di lettura al secondo. Quattro thread su core fisici separati, invece di 8,9–11,6 milioni, hanno eseguito 25–26 milioni di operazioni. Un singolo thread si è accelerato in modo significativamente più modesto, da 7,9–8,1 milioni a 8,8–8,9 milioni di letture al secondo. Il numero di cicli di CPU per operazione con otto thread è diminuito da circa 2950 a 725.

Ulteriori misurazioni hanno confermato che la modifica elimina la competizione tra i core di elaborazione. Il numero di eventi Load HITM nel test con otto thread è sceso da 30.538 a 101. Torvalds ipotizza che sui server multiprocessore il guadagno potrebbe essere ancora più evidente, ma non ha ancora verificato l’ipotesi. Tutti i risultati pubblicati sono stati ottenuti su un singolo laptop con quattro core fisici e otto thread, sistema di file ext4 e alcuni meccanismi di protezione del kernel disattivati.

L’accelerazione ha rivelato un lato negativo. Il rilascio posticipato delle pagine può aumentare il consumo di memoria operativa, soprattutto quando i programmi creano e cancellano intensamente i dati. In uno dei test di una versione preliminare delle patch, il sistema con 2 GB di memoria operativa ha attivato prematuramente il meccanismo OOM Killer, che termina forzatamente i processi in caso di carenza di memoria. Ulteriori modifiche hanno permesso di superare il test, ma non hanno risolto completamente il problema del conteggio delle pagine in attesa di rilascio.

Nonostante i test locali riusciti, le patch non hanno ancora superato una verifica completa. Lo sviluppatore non ha eseguito il set standard di test di file xfstests, non ha utilizzato KASAN per la ricerca di errori di accesso alla memoria e non ha testato le build a 32 bit. Non sono stati eseguiti test su altri computer e con alcune configurazioni del kernel. Per un sottosistema così sensibile come la gestione della memoria, tali limitazioni non permettono ancora di considerare il nuovo algoritmo pronto per un uso diffuso.

Per Linux, l’esperimento è interessante non solo per i risultati dei test, ma anche per il metodo di sviluppo. Il creatore del kernel ha affidato a Claude Code il lavoro con i meccanismi di basso livello di gestione della memoria, dove un errore può portare a danni ai dati, al malfunzionamento del sistema o alla comparsa di vulnerabilità. Al tempo stesso, Torvalds non ha nascosto il coinvolgimento dell’IA e ha dettagliato i limiti della soluzione proposta. Finora, i risultati pubblicati dimostrano solo la possibilità di un’accelerazione sostanziale di uno scenario specifico, non un triplicazione delle prestazioni complessive di Linux.

Carolina Vivianti

Carolina Vivianti è consulente/Advisor autonomo in sicurezza informatica con esperienza nel settore tech e security. Ha lavorato come Security Advisor per Ford EU/Ford Motor Company e Vodafone e ha studi presso la Sapienza Università di Roma.

Aree di competenza: Cybersecurity, IT Risk Management, Security Advisory, Threat Analysis, Data Protection, Cloud Security, Compliance & Governance