Linus Torvalds: Claude Code ha scritto patch e test per il kernel Linux

• Torvalds ha usato Claude Code per patch, test e bozza di relazione sulla page cache di Linux
• Otto patch con RCU: 30–33 milioni di letture/s contro 9,9–10,4 milioni, su un benchmark ristretto
• Restano problemi di memoria e test incompleti (KASAN, lockdep, altre architetture)
• Servono ulteriori test e revisioni prima di validare le prestazioni

Linus Torvalds ha reso noto che Claude Code, lo strumento di programmazione assistita di Anthropic, lo ha aiutato a scrivere patch per il kernel Linux, programmi di test, materiale di revisione e la prima bozza di una relazione tecnica. Il lavoro è stato svolto sotto la sua direzione e riguarda le prestazioni di lettura della page cache.

Un lavoro supervisionato

Non si tratta di un sistema di intelligenza artificiale che mantiene Linux in autonomia. Il caso mostra come questi strumenti entrino nello sviluppo di un sistema operativo e come i loro limiti vengano documentati apertamente. Torvalds precisa inoltre che le misure sono state eseguite sul suo computer.

Cosa fanno le patch

La serie di otto patch interviene su un collo di bottiglia. Succede quando molti thread eseguono piccole letture dallo stesso file in cache. Ogni lettura aggiorna di norma il contatore dei riferimenti di un folio, cioè un gruppo di pagine di memoria. Gli aggiornamenti ripetuti costringono i core del processore a contendersi gli stessi dati.

L’approccio proposto rimanda il riutilizzo della memoria rimossa dalla page cache fino alla fine di un periodo di grazia RCU. In questo modo i lettori attivi hanno il tempo di terminare prima che quella memoria sia usata per altro. Con questa protezione, il nuovo percorso di lettura può copiare i dati senza acquisire e rilasciare i riferimenti al folio. Se non è possibile usare il percorso rapido, ad esempio per dati assenti dalla cache o per un errore sul buffer utente, la lettura prosegue con il percorso esistente.

I risultati

Nel messaggio del commit del 10 ottobre, Torvalds riporta che otto thread su un laptop Intel con quattro core e otto thread hanno raggiunto circa 30–33 milioni di letture da 16 byte al secondo da un file in cache. Il riferimento di base era di 9,9–10,4 milioni.

Il dato vale per un benchmark circoscritto e non per le prestazioni complessive di Linux. I test hanno usato ext4, con le mitigazioni di sicurezza del processore e CONFIG_HARDENED_USERCOPY disattivate. Non è stata provata una macchina più grande. Alcune letture con pagine di memoria utente mancanti sono diventate più lente.

Limiti e punti aperti

• La memoria liberata in ritardo può restare in attesa di riuso senza che l’allocatore la conteggi correttamente. Patch successive hanno ridotto l’accumulo, ma la relazione elenca ancora problemi di allocazione irrisolti. Inoltre non c’è un limite certo ai tempi se i periodi di grazia sono lenti.
• Un test ha cercato dati errati durante ripetute espulsioni e riusi di pagine. Nelle esecuzioni normali non sono state rilevate letture errate. Una versione volutamente difettosa ha invece restituito byte sbagliati, compresi dati di altri utilizzatori della memoria liberata.
• I test non hanno coperto KASAN, lockdep, hardened usercopy, altre architetture e diversi scenari di stress.

Cosa significa

L’AI può supportare sviluppo e analisi. Le patch, però, richiedono test e revisioni più ampi prima che carichi di lavoro reali possano confermare i guadagni di prestazioni e le garanzie sulla sicurezza della memoria.

Fonte: Cyber Security News · Foto: Cyber Security News