Skip to content

OpenDPD 2.4.2

The hosted Studio VM now returns unused guest pages to the host through virtio-balloon-pci,free-page-reporting=on. Its qcow2 disk uses cache=none to avoid keeping a second disk cache in host RAM. The guest still has 8 GiB of addressable memory, four vCPUs, a 6 GiB API service limit and the existing session, workspace and GPU limits. Waveform synthesis, precision, metrics and training algorithms are unchanged.

The deployment locks also update filelock to 4.2.1 and setuptools to 84.1.0 to pass the current vulnerability audit. API and GPU runtimes are staged with these exact hashed wheels before activation.

The previous deployment showed about 4.8 GiB of QEMU RSS while the guest used about 720 MiB and the API process about 240 MiB. Thread views can repeat the same process RSS for every QEMU thread; those rows must not be added. Guest capacity, process RSS, reclaimable file cache and cgroup usage measure different things. Free-page reporting releases only guest pages that the guest kernel reports as unused; it does not evict active workspaces or reduce the available capacity. The guest keeps its own disk cache, and direct I/O continues to honor disk flushes.

Updating the host VM unit requires restarting the VM. Drain running/queued jobs first, keep the prior source, runtime, image and unit for rollback, activate the matching API/GPU source, then publish the Studio site. As with other hosted restarts, existing temporary sessions expire.

To record residency and verify repeated allocation/release during a drained maintenance window:

sudo python3 deployment/web/measure-memory.py --exercise-mib 1024 --output /tmp/opendpd-memory.json

Without --exercise-mib, the command only measures. It never flushes caches or reads workspace contents. Repeated synthetic allocation is supplemented by the hosted admission benchmark, real waveform generation, browser checks and the PA/DPD training and inference smoke journey during rollout.

References: Linux free-page reporting, QEMU disk cache options.