Torvalds usa Claude Code per riscrivere la page cache di Linux

Quando a mettere le mani sul kernel Linux con un assistente di programmazione basato su AI è lo stesso Linus Torvalds, la notizia fa il giro del mondo in poche ore. Il creatore di Linux ha pubblicato nel suo albero un ramo sperimentale di otto patch che cambia il modo in cui il sistema operativo legge i dati dalla page cache, e ha dichiarato apertamente che codice, programmi di test e prima bozza della documentazione sono stati prodotti con Claude Code, sotto la sua direzione.

Non è una semplice curiosità. È un segnale concreto di quanto gli agenti di coding siano entrati nel lavoro quotidiano anche dei progetti più esigenti e conservativi del software mondiale.

Cosa ha pubblicato Torvalds nel suo albero del kernel

Il lavoro si chiama noref-filemap-read-with-llm ed è un ramo di otto patch basato su Linux 7.3-rc6, con un commit intitolato “mm: read from the page cache without folio references”, datato 10 ottobre. Il ramo si trova nell’albero principale di Torvalds su git.kernel.org ed è stato notato da osservatori del mondo Linux poco prima del tag 7.3-rc7. Al momento si tratta di un esperimento, non di una modifica entrata nel ramo principale.

Nel messaggio di commit, Torvalds spiega che Claude Code ha prodotto il codice, i programmi di prova, la revisione che ha portato all’elenco dei problemi ancora aperti e la prima stesura del testo. Le misurazioni, invece, le ha eseguite lui stesso sul suo computer.

Il problema: contatori che si contendono la stessa riga di cache

Ogni volta che il kernel legge un piccolo pezzo di un file già presente in memoria, deve prendere e poi rilasciare un riferimento alla struttura (il folio) che contiene quei dati. Sono scritture atomiche su un contatore condiviso, e quando molti thread leggono lo stesso file la stessa riga di cache rimbalza continuamente da un core all’altro. Il collo di bottiglia era già noto: secondo le ricostruzioni, era emerso nel 2024 da un carico di lavoro di un cliente segnalato da Matthew Wilcox.

Tentativi precedenti copiavano i dati in un buffer temporaneo e li convalidavano dopo, ma si arenavano su condizioni di gara che la convalida non riusciva a intercettare.

La soluzione: leggere senza prendere riferimenti

Torvalds ha scelto un’altra strada, basata sul meccanismo RCU (Read-Copy-Update) del kernel. I folio che escono dalla page cache non vengono liberati subito, ma solo dopo un periodo di grazia RCU. In questo modo chi legge, restando dentro una sezione di lettura RCU, può copiare i dati direttamente dalla pagina senza alcun riferimento, senza buffer intermedio e senza limiti sulla dimensione della lettura.

L’idea è elegante, ma sposta il costo altrove: la memoria resta occupata un po’ più a lungo prima di poter essere riutilizzata.

I numeri del test, e perché vanno letti con cautela

I benchmark sono stati eseguiti su un portatile con Intel Core i7-8565U, quattro core e otto thread, con alcune mitigazioni di sicurezza del kernel disattivate e filesystem ext4. Il test principale usa otto thread che eseguono letture da 16 byte sulla stessa pagina in cache.

In questo scenario i cicli di kernel per lettura scendono da circa 2.950 a circa 725, e il throughput sale da circa 10 milioni a 30-33 milioni di letture al secondo, cioè quasi il triplo. Anche con un solo thread c’è un miglioramento di circa il 10% per lettura, mentre le collisioni misurate con perf c2c crollano da oltre 30.000 a poco più di cento.

Il triplo vale solo per quel carico specifico.

Le patch introducono anche dei compromessi. In un caso particolare, la lettura di 16 byte verso una pagina utente non ancora mappata passa da circa 4.150 a circa 6.550 cicli, perché ora richiede un’eccezione fallita prima del ripiego sul percorso classico. Torvalds stesso definisce la gestione della memoria differita come “la parte meno risolta” della serie. Due patch aggiungono una valvola di sicurezza: quando una CPU accumula oltre 1.024 pagine in coda, un worker forza un periodo di grazia accelerato. In un test di stress su una macchina virtuale da 2 GiB, la versione a sei patch ha fatto intervenire l’OOM killer su 4 e 8 CPU, mentre la serie completa ha funzionato su 1, 2, 4 e 8 CPU.

Infine, tutto è stato provato su un solo portatile. Torvalds si aspetta guadagni maggiori su macchine più grandi e multi-socket, ma ammette che nulla di simile è stato ancora testato. Servirà qualcuno che ripeta le misure su un server con molti core, e il via libera dei maintainer della gestione della memoria.

Perché questa notizia conta per chi sviluppa software

Il kernel Linux è uno dei progetti software più rigorosi e più revisionati al mondo. Vedere il suo creatore descrivere con trasparenza il ruolo di un agente AI, compresi i limiti e le questioni irrisolte, è un precedente culturale importante. Non si parla di “codice generato che funziona per magia”, ma di un flusso in cui l’umano imposta il problema, valuta le alternative, misura i risultati e decide cosa tenere.

È lo stesso schema che vediamo emergere in altri ambiti. Anthropic sta spingendo Claude verso compiti sempre più tecnici, come racconta il nostro approfondimento sull’Anthropic Cyber Mission per infrastrutture critiche e open source, e ha reso più accessibili i suoi modelli con uscite come Claude Haiku 5.5, con prezzi ridotti del 75%, e Claude Sonnet 5.5, più veloce ed economico.

Che cosa cambia nella pratica

Per i team di sviluppo, il messaggio è che un agente di coding rende al meglio quando riceve un obiettivo chiaro, una metrica misurabile e un revisore umano competente. Il lavoro di Torvalds mostra tutti e tre gli ingredienti: il problema era noto da anni, il criterio di successo era un numero (letture al secondo), e la responsabilità finale è rimasta a lui.

Per chi usa questi strumenti ogni giorno, ci sono almeno tre lezioni pratiche da portare a casa:

• chiedi sempre all’agente di produrre anche i test e i benchmark, non solo il codice;
• misura tu stesso i risultati sulla tua macchina, senza fidarti di stime generiche;
• documenta apertamente il contributo dell’AI nel commit, come ha fatto Torvalds.

Va ricordato anche il contesto: negli ultimi mesi i modelli di coding sono passati da semplici suggeritori di righe a veri collaboratori capaci di lavorare su più file, scrivere programmi di prova ed eseguire misurazioni. Il caso del kernel è un banco di prova severo proprio perché ogni modifica deve convincere persone molto scettiche e attente alla stabilità.

Che cosa aspettarsi adesso

La strada verso l’inclusione nel kernel è ancora lunga. Le patch dovranno superare la revisione dei maintainer della memoria, dimostrare di non causare regressioni e reggere test su hardware molto diverso da un portatile del 2019. Non è escluso che la forma finale della soluzione cambi parecchio, o che il lavoro venga rimandato.

Resta però un fatto: uno dei più celebri programmatori al mondo ha usato uno strumento come Claude su un componente centrale del kernel, e lo ha detto chiaramente. Per il dibattito sull’uso dell’AI nell’open source, questo vale più di mille opinioni.

Conclusioni

L’esperimento di Torvalds non dimostra che l’AI possa scrivere il kernel da sola, e nessuno dei protagonisti lo sostiene. Dimostra invece che, in mani esperte e con metriche chiare, un agente di coding può accelerare un lavoro di ottimizzazione che resisteva da anni. Se sviluppi software, è il momento di provare un flusso simile su un tuo collo di bottiglia reale: scegli un problema misurabile, affida all’agente codice e test, e verifica tutto con i tuoi numeri. Seguici per gli aggiornamenti su cosa decideranno i maintainer del kernel.