---
type: "post"
id: "kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297"
slug: "kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297"
title: "Kiryl Shutsemau posts reworked 18-patch RFC of Torvalds' LLM-assisted lockless page-cache read series"
description: "Kiryl Shutsemau of Meta has posted a reworked 18-patch Linux memory-management RFC derived from Linus Torvalds' LLM-assisted lockless page-cache read work."
retrieval_nugget: "Kiryl Shutsemau of Meta has posted a reworked 18-patch Linux memory-management RFC derived from Linus Torvalds' LLM-assisted lockless page-cache read work. It matters because the work is now being tested through ordinary kernel review, where correctness, memory-reclamation cost, and operational observability—not an AI authorship claim—determine whether it advances."
published_at: "2026-10-28"
updated_at: "2026-10-28"
record_date: "2026-10-28"
date_kind: "published_at"
topics: []
entities: ["Linux","Kiryl Shutsemau","Linus Torvalds","Meta","PG_rcu_free","CONFIG_PAGE_RCU_FREE"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Shutsemau has posted a reworked 18-patch RFC of the page-cache series previously published by Torvalds; it remains a proposal, not an accepted kernel change."
prior_refs: ["memory:4de30ff6-f659-80ec-ad28-5d6223e473ae","memory:37568caf-f916-83a8-a3e9-6272bb5a126b"]
source_url: "https://lore.landau.one/lkml/20261019154913.1765974-2-kas@kernel.org"
source_urls: ["https://lore.landau.one/lkml/20261019154913.1765974-2-kas@kernel.org"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297/","markdown":"https://newruntime.com/posts/kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297.md","json":"https://newruntime.com/posts/kiryl-shutsemau-posts-reworked-18-patch-rfc-of-d0e297.json"}
---

# Kiryl Shutsemau posts reworked 18-patch RFC of Torvalds' LLM-assisted lockless page-cache read series

## Retrieval answer

Kiryl Shutsemau of Meta has posted a reworked 18-patch Linux memory-management RFC derived from Linus Torvalds' LLM-assisted lockless page-cache read work. It matters because the work is now being tested through ordinary kernel review, where correctness, memory-reclamation cost, and operational observability—not an AI authorship claim—determine whether it advances.

## Summary
Kiryl Shutsemau of Meta has posted a reworked 18-patch Linux memory-management RFC derived from Linus Torvalds' LLM-assisted lockless page-cache read work. It matters because the work is now being tested through ordinary kernel review, where correctness, memory-reclamation cost, and operational observability—not an AI authorship claim—determine whether it advances.

## What happened
On October 19, 2026, Kiryl Shutsemau posted an 18-patch request-for-comments series to the Linux memory-management lists. The series reworks a line of page-cache changes associated with Linus Torvalds' development work. Its stated aim is to let CPUs reading the same file avoid bouncing a page-cache folio's reference count, a source of contention when many CPUs repeatedly perform small reads from one file.

The first patch introduces a page flag named `PG_rcu_free`. The core safety problem is straightforward: a reader that does not take a reference to a folio could otherwise keep copying from it after it has been freed and its memory reused. Under the proposed design, a flagged folio is not freed until an RCU grace period has passed. A lockless reader that sees the flag while holding `rcu_read_lock()` and still finds the folio at its expected location may continue reading it until `rcu_read_unlock()`.

The patch describes several implementation details. The flag is copied when a folio is split, because a reader may still be reading the resulting folios. Rather than queueing an RCU callback for every folio in a truncated file, the proposal places folios on per-CPU lists and allows one grace period in flight per CPU. A work item, which may reschedule, frees each batch. Since reclaim depends on those frees, the workqueue is marked `WQ_MEM_RECLAIM`.

Shutsemau's rework changes the approach to flagging at read time, limits the configuration to 64-bit systems, and shortens comments and changelog material. The configuration is named `CONFIG_PAGE_RCU_FREE`; the patch says 32-bit page flags are scarce and that the avoided contention is principally a large-machine concern. It also adds a `pgfree_rcu` counter to `/proc/vmstat` for deferred pages. The first patch explicitly says that nothing sets the flag yet, underscoring that this is infrastructure for later patches rather than a completed user-visible feature.

The patch retains Torvalds as author and carries both `Assisted-by: LLM` and Torvalds' sign-off, while Shutsemau signs the rework. This is an RFC under review, not a merged Linux feature, and the supplied material establishes neither final performance results nor a timetable for inclusion.

## What the archive adds
This is a new fact on a known story: the earlier work has moved from Torvalds' development branch into a reworked RFC submitted by Shutsemau. Earlier coverage framed the important threshold as AI-assisted kernel work entering an inspectable patch-and-review process rather than resting on an authorship claim: [kernel/git/torvalds/linux.git - Linux kernel source tree](https://newruntime.com/posts/kernel-git-torvalds-linux-git-linux-kernel-source-fe3569/). Two later notes covered Torvalds' position against AI-specific submission restrictions: [Linus Torvalds on LKML](https://newruntime.com/posts/linus-torvalds-on-lkml-rules-against-using-ai-2a65c2/) and [Linus Torvalds Rejects AI Coding Bans](https://newruntime.com/posts/linus-torvalds-rejects-ai-coding-bans-as-linux-be23ea/).

## Trend signal
No supplied pattern genuinely fits this kernel-memory RFC closely enough to support a pattern claim.

## Why it matters
For teams building with AI, the significant point is not that a model was credited in a patch header. The series shows the harder transition: AI-assisted work has to survive handoff, redesign, review, and integration by maintainers other than the original author. The proposal exposes concrete trade-offs that cannot be resolved by generated code alone: reduced reference-count contention is exchanged for deferred memory reuse after an RCU grace period; the design needs reclaim-safe freeing; and it adds an operational counter so deferred pages can be observed.

That is a useful production analogy. Agent-generated changes should arrive with a clear safety model, measurable side effects, and a path for another engineer to revise them. A patch being inspectable is necessary, but it is not evidence that it is ready to ship. Here, the RFC label and the statement that no code yet sets the new flag make that distinction unusually explicit.

## Limits and uncertainty
The supplied source is the first patch of an RFC series and a summary of the series' rework. It does not provide benchmark data, comparison against existing page-cache reads, or evidence that the proposal improves a workload in practice. It does not say which later patches will activate `PG_rcu_free`, whether reviewers accept the memory-reuse trade-off, or whether the series will be merged. The LLM assistance attribution identifies assistance, not the extent of model involvement or the quality of its contribution. No conclusion about production Linux behavior should be drawn from this RFC alone.

## Reader takeaway
An LLM-assisted Linux change is now being carried forward as a reworked RFC, where its value will be judged through ordinary systems engineering: race safety, reclamation behavior, observability, review, and eventual workload evidence. The meaningful signal is the reviewable handoff, not the attribution line.

## Open question
Can the later patches demonstrate that avoiding folio reference-count contention outweighs the cost of deferring memory reuse on the large systems this design targets?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)