- Book: AI Agents Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
The branch name gives it away: noref-filemap-read-with-llm. Linus Torvalds pushed it to his own Linux tree, and Phoronix spotted it while waiting for the Linux 7.3-rc7 tag (Hardware Busters).
It holds eight patches that rework how the page cache serves small reads, built on top of Linux 7.3-rc6. The cover letter credits Claude Code, Anthropic's coding agent, with the code, the test programs, the review behind the list of open problems, and the first draft of the cover letter itself, all under Torvalds' direction (Hardware Busters, It's FOSS).
On his laptop, eight threads reading one file went from about 10 million to 30–33 million reads per second (It's FOSS). The series is not merged (Hardware Busters).
For anyone shipping agent-written code, the packaging matters more than the 3x: the cover letter says who did which part and lists what is still broken.
What the patches change
Every small read from the page cache takes a reference on a folio and then drops it. Those are atomic writes to the same cache line, so when many cores read one file, that line bounces between them. With eight threads doing 16-byte pread() calls on Torvalds' Core i7-8565U laptop, that single line accounted for 99.92% of cross-core load HITMs (Hardware Busters). A kernel developer flagged the bottleneck in 2024, citing a customer's workload (It's FOSS).
The fix leans on RCU. A folio that leaves the cache goes back to the page allocator only after a grace period, so a reader can copy straight from the page without touching the reference count. The price is memory that sits idle for a short while before it can be reused (It's FOSS). Two of the eight patches add a safety valve that forces an expedited grace period once a CPU has more than 1,024 pages queued, and Torvalds still calls the deferred freeing "the part of this series that is least solved" (Hardware Busters).
Before: every reader grabs the same counter. After: readers copy through, and freed pages wait out a grace period.
The numbers, including the ones that went the wrong way
Everything below comes from one 4-core, 8-thread laptop with CPU mitigations disabled, as reported by Hardware Busters:
| Test | Before | After |
|---|---|---|
| 8 threads, one file: cycles per read | ~2,950 | ~725 |
| 8 threads, one file: reads per second | 9.9–10.4M | 30–33M |
| 1 thread: cycles per read | 452–454 | 408–409 |
| perf c2c load HITMs | 30,538 | 101 |
| 1 thread, 16-byte read into an unmapped user page | ~4,150 cycles | ~6,550 cycles |
The last row is a regression, and it sits in the published numbers next to the wins. So does a memory stress result: in a 2 GiB VM, the six-patch version, before the two safety-valve patches, let the OOM killer fire on 4 and 8 CPUs, while the full series completed on 1, 2, 4 and 8. Torvalds expects larger and multi-socket machines to gain more, but nothing that size has been tested (Hardware Busters).
Treat the 3x as one data point on one machine, measured by the person who directed the series. Test the branch on your own hardware before you quote that number about your servers.
Read the cover letter as a review checklist
The split of work is stated plainly. The agent produced everything credited above under Torvalds' direction, and the benchmarks ran on his own machine (Hardware Busters).
That maps onto four habits you can copy for any agent-written change you send to a team:
- Say in the branch name or PR title that an agent wrote it. Reviewers adjust how they read.
- Run the numbers yourself, on hardware you name. The agent can write the benchmark; you own the result.
- Publish the regressions next to the wins, with the same precision.
- Keep an open-problems list, and let the agent help write it. An agent asked to review its own work is cheap to run before anyone else spends time on it.
This is not a one-off for him. It's FOSS also links an earlier AI-assisted fix for an Intel Xe graphics driver bug. And at Open Source Summit Europe in Prague, Torvalds said "I actually really like using AI," as quoted by ZDNet and It's FOSS.
The human directs and measures. The agent writes. The work stays on its own branch until it earns a merge.
The kernel already has a rule for this
You don't have to invent a disclosure format. The kernel's AI Coding Assistants guide asks contributions to carry an Assisted-by: LLM [TOOL1] [TOOL2] tag, where the tools are optional analysis tools such as coccinelle or sparse. It also says "AI agents MUST NOT add Signed-off-by tags," because only a human can certify the Developer Certificate of Origin. The human reviews all AI-generated code and takes full responsibility for it.
You can adopt the same convention in your own repo with plain git. Add the trailer and your own sign-off when you commit:
git commit -s --trailer "Assisted-by: LLM"
Then a reviewer can list which commits on a branch were agent-assisted:
git log main..HEAD \
--format='%h %s %(trailers:key=Assisted-by)'
The --trailer option and the %(trailers) placeholder are standard git.
Where Hermes IDE fits
I build Hermes IDE, so weigh this section with that in mind. The shape of Torvalds' branch, agent work on its own named branch and reviewed in pieces, is the workflow Hermes is built around. ⌘N starts each task on its own hermes/<name> branch in its own worktree, every agent turn is saved so you can diff or restore a single turn, and the Review Desk (⌘G) shows changes by turn or by file (Hermes README). It runs Claude Code in a real terminal next to other agents. It does not run your benchmarks or write your open-problems list; that part stays yours. Hermes is free, source-available and on macOS, Windows and Linux, and it is not affiliated with Anthropic or the Linux Foundation.
If this was useful
If you hand work to coding agents, try the four habits from Torvalds' cover letter on your next agent branch, and Hermes IDE gives each of those branches its own worktree and a turn-by-turn review. If you build agents yourself, the AI Agents Pocket Guide covers the patterns behind tools like Claude Code.
Top comments (0)