Hello Albert. On Mon, Jul 06, 2026 at 02:06:39PM +0200, Albert Esteve <[email protected]> wrote: > Hi all, > > This small series adds practical test coverage for the dmem > cgroup controller. > > The motivation came from following the recent dmem API discussion in > thread [1]. That discussion considered changing the dmem API and > adding a new knob. Currently there are no dedicated tests covering > dmem behaviour, which makes such changes riskier. > > Adding selftests has an additional challenge: dmem charging paths > are driver-driven today, so regression testing is harder unless a > suitable driver is present in the test environment. > > This series addresses that by adding: > - a kernel-side selftest helper module to trigger charge/uncharge > from userspace in a controlled way, > - cgroup selftests covering dmem accounting and protection semantics > (including dmem.max enforcement and byte-granularity checks), > - a virtme-based VM runner for repeatable execution of the dmem tests. > > The goal is to make dmem behavior easier to validate when evolving the API > and implementation, while keeping tests deterministic and driver-independent.
Thanks for the dmem selftesting. I'll respond to first two patches individually. I find the wrapper scripts in the last two a bit of an overkill for the selftest (as it adds dependency on particular VM environment, I'd keep the simplicity of selftests such that wherever they are executed (w/out wrappers), there they run (be it a physical machine or a VM). At most, I'd consider a simple wrapper that'd load ensure the test module is loaded. Thanks, Michal
signature.asc
Description: PGP signature
