[zhaoyuuu0624]

Allow pVisor's existing user-space UKSM-style page sharing to work with offload and backing compression through the opt-in shared_backing profile. Defaults and existing offload policies remain unchanged. This is not Linux kernel UKSM/KSM.

Before reclaim, write replaced pages, including COW modifications and zero pages, back to their backing offsets under the existing CPU/device barrier. Use the same path for automatic guest-idle offload. Also drain pending vCPU controls before KVM re-entry so a consumed wakeup cannot strand a queued request; retain the existing deadlines and fail-stop behavior.

Validation

Dual-VM tests cover offload/restore, write isolation and independent shutdown. The repaired historical runtime passed 36 related tests, full s14, and all 16 replay trajectories with strict cleanup, no observed control timeout and zero OOM/swap. Per-task official outcomes match across all three arms; 3/16 fully pass official tests.

Same first 16 trajectories, simultaneous arrivals, original model waits, 32 GiB budget and CPU/admission settings; no real model calls. Both pVisor arms use offload and backing compression. AgentENV uses the corrected initialization adapter.

Arm	Controller elapsed (min)	Mean queue (s)	Parent peak (GiB)	Parent integral (GiB·s)
pVisor offload	59.50	35.88	20.45	49038
pVisor offload + UKSM	77.89	106.63	32.00	75487
AgentENV	145.48	105.88	27.47	213842

“UKSM” above means pVisor user-space UKSM-style sharing. The shared arm is slower and uses more charged memory than offload alone; this PR establishes compatibility, not a performance improvement. Excluding s15 does not reverse that observation.

These are single-run engineering observations from historical builds, including a backport of the repair, not a replay run using the review checkout binary itself. Parent-memory/cache attribution differs across backends, so the memory columns do not establish fair whole-host savings. Timing and integration details, s15-excluded averages and validation provenance are in VALIDATION_NOTES.txt; full-precision per-task data is in RESULTS.json.

Submission checks: rebased onto latest main (3d6fbc9) without conflicts; 36 related unit tests passed in the minimal-dependency Linux/KVM validation workspace. No replay experiments were rerun.

[zhaoyuuu0624]

AgentENV’s longer overall runtime is dominated by s15, particularly its unrestricted filesystem search in step 17.

These measurements replay the same 4 tasks × 4 recorded rollout trajectories, preserving recorded model waits without live model inference.

Metric	pVisor offload	pVisor offload + UKSM-style sharing	AgentENV
Full 16-trajectory batch duration	59.50 min	77.89 min	145.48 min
s15 replay duration	57.97 min	73.83 min	142.41 min
Remaining 15: mean replay duration	23.74 min	46.14 min	22.13 min
Remaining 15: mean cumulative tool time	41.78 s	215.44 s	9.41 s
Remaining 15: mean queue time	33.98 s	101.94 s	100.89 s

Replay duration includes recorded model waits and excludes queue time. Both pVisor configurations retain backing compression.

Why is s15 slow? Earlier targeted diagnostics isolated the delay to grep, rather than find: the search traverses /proc, including large virtual files such as kcore and pagemap. In that diagnostic run, path sampling attributed approximately 48 minutes to kcore and 77 minutes to pagemap on AgentENV. The pVisor guest kernel disables CONFIG_PROC_KCORE, and its sampled process/thread layout exposed fewer pagemap paths. This makes the effective scan workload different between environments; it does not establish a general AgentENV performance defect or an offload speedup.

Excluding s15, AgentENV has the shortest mean replay and tool execution times, although pVisor offload has less queueing. This is post-hoc filtering of the original concurrent runs, not a separate 15-trajectory experiment; contention from s15 remains reflected in the measurements.