From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: mm: Wire up order in shrink_control Date: Tue, 05 May 2026 10:13:40 +1000 Message-ID: In-Reply-To: <20260430182335.2132382-2-matthew.brost@intel.com> References: <20260430182335.2132382-1-matthew.brost@intel.com> <20260430182335.2132382-2-matthew.brost@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Overall:** Clean mechanical change that plumbs `sc->order` from `scan_con= trol` through `shrink_slab` into `shrink_control`. This is the right way to= give shrinkers visibility into allocation order. **Positive:** - Type choice of `s8` is consistent with `scan_control.order` in `mm/vmscan= .c:153`. - All three `shrink_slab` call sites in vmscan.c are updated. `drop_slab_no= de` correctly passes 0 since it isn't order-driven reclaim. **Minor observations:** - The `shrink_control.order` field is added between `nid` and the existing = comment block for `nr_to_scan`. This is fine structurally, though adding it= after `memcg` would keep the "reclaim context" fields grouped. Not a block= ing concern. - The `shrink_slab_memcg` function at line 270 receives the `order` paramet= er but the `#ifdef CONFIG_MEMCG` guard means this code is conditionally com= piled. Both the memcg and non-memcg paths correctly initialize `sc.order = =3D order` =E2=80=94 good. **Question for mm maintainers:** Is there interest in making `order` availa= ble to shrinkers generically, or would the mm community prefer this to stay= driver-side? The commit message mentions "detecting high-order allocation = pressure or fragmentation" as the motivation, which is reasonable, but the = field is unused by any existing shrinker in this series. --- Generated by Claude Code Patch Reviewer