From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Insert instead of copy pages into shmem when shrinking Date: Sat, 16 May 2026 13:43:39 +1000 Message-ID: In-Reply-To: <20260512110339.6244-1-thomas.hellstrom@linux.intel.com> References: <20260512110339.6244-1-thomas.hellstrom@linux.intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: Insert instead of copy pages into shmem when shrinking Author: =3D?UTF-8?q?Thomas=3D20Hellstr=3DC3=3DB6m?=3D Patches: 19 Reviewed: 2026-05-16T13:43:39.916433 --- This 2-patch series from Thomas Hellstr=C3=B6m introduces a zero-copy path = for TTM buffer object shrinking. Instead of allocating shmem pages and copy= ing data into them (the current approach), TTM pages are inserted directly = into the shmem page cache, avoiding both the memory overhead and the fragme= ntation caused by splitting high-order pages at shrink time. The motivation= is sound: under memory pressure, having to allocate a full high-order page= just to copy into it before freeing the original defeats the purpose of sh= rinking. The architecture is clean: Patch 1 adds a general `shmem_insert_folio()` in= terface in mm/shmem with appropriate preconditions and assertions, and Patc= h 2 rewires TTM to use it. The series touches core mm code (`mm/page_alloc.= c`, `mm/shmem.c`) which will require mm maintainer sign-off (Andrew Morton = and/or the relevant mm reviewers are CC'd). Both patches carry `Assisted-by: GitHub_Copilot:claude-sonnet-4.6`, indicat= ing AI assistance in development. Given the complexity of the mm interactio= ns and the subtlety of compound page lifecycle management, this warrants ca= reful scrutiny =E2=80=94 several of the issues below may reflect areas wher= e AI-generated code follows patterns without fully accounting for the write= back protocol. **Key concerns:** 1. The writeback path in `shmem_insert_folio()` skips `folio_clear_dirty_fo= r_io()` and `folio_set_reclaim()` before calling `shmem_writeout()`, deviat= ing from the protocol used both by the writeback infrastructure and by the = old TTM code. 2. `undo_compound_page()` is exported globally but is a very sharp tool =E2= =80=94 it's only safe under narrow preconditions that aren't enforced at ru= ntime. 3. The EEXIST handling in `shmem_insert_folio()` silently truncates existin= g content, which may mask logic bugs in callers. --- --- Generated by Claude Code Patch Reviewer