tasks/task_save: stop reallocating and copying the undo snapshot on every state load

[LibretroAdmin]

tasks/task_save: stop reallocating and copying the undo snapshot on every state load

Follow-up to #19314. That PR made the save/load transfer loops budget-bound, which moved the bottleneck: the budgeted quantum loops are now a minority of the cost and never stall a frame, and what's left is unsliced. Profiling the merged code showed the largest remaining single-frame stall on the load path isn't the file I/O at all — it's a serialize nobody looks at.

content_load_state_cb calls content_save_state(path, false) before every state load, to capture the undo snapshot. That's a full core_serialize, on the main thread, in the same tick as the deserialize that follows it. It ran into a freshly malloc'd buffer every time. And content_undo_load_state then malloc'd a full-size temporary and copied the whole state into it a second time.

Two commits: keep the capture's buffer, then stop copying it during undo.

---

1. Keep the snapshot's allocation instead of reallocating it

A state-sized allocation is served by mmap rather than out of the heap's free lists, so free() hands the pages straight back to the kernel and the next capture faults every one of them in again on first touch. That fault traffic is not a rounding error next to the copy it exists to hold — measured in isolation against a 16 MiB state, a fresh malloc plus the copy costs 5.08 ms where the copy into a retained buffer costs 1.88 ms.

content_serialize_reusing() serializes into a caller-owned buffer, allocating only when what's there is too small. content_save_state() swaps the filled spare with the live snapshot rather than freeing and assigning.

Swapping rather than writing in place is load-bearing, not incidental. Serializing straight over the live snapshot would leave a half-written one that still looks valid, so an undo after a failed capture would restore garbage. Filling the spare first means the live snapshot is untouched until a complete one is ready to replace it — which is exactly what the fresh-allocation form did. There's a test for it.

The spare is only ever held when undo is enabled: content_save_state returns before reaching any of this when save_state_disable_undo is set. That setting is a statement that memory is scarce, and it still means one buffer rather than two.

struct save_state_buf gains a capacity field. Only undo_load_buf needs it — it's the only buffer whose allocation may outlast a snapshot of a different length — but it's maintained on all three users so the next person to reuse the struct can't read it stale.

2. Detach the snapshot during undo instead of copying it

content_undo_load_state restores the snapshot in undo_load_buf, but first captures the current state over that same buffer so the undo is itself undoable. It resolved that with a full-size temporary and a whole-state memcpy — a second state-sized allocation and a second full copy, on top of the capture's own, in one unsliced call on the main thread.

Detaching does the same job for nothing. After the detach undo_load_buf owns no buffer, so the capture serializes into the spare and swaps that in, and neither the capture nor the swap can touch the bytes being restored — which is the only thing the copy was protecting. Afterwards the detached allocation has no owner, so it becomes the next spare rather than going back to the kernel.

In steady state the whole undo path allocates nothing and copies the state exactly once, into the core.

One behaviour is preserved deliberately: if the capture fails, the detached snapshot goes back into undo_load_buf rather than to the spare, leaving the buffer holding what the copy-based form left it holding in that case. Without that, the failure path would silently empty the undo buffer.

---

Before / after

Median of fifteen. Intel Xeon @ 2.10 GHz (1 vCPU), ext4 on virtio, GCC 13.3.0, -O2.

Measurement note, because it changes the numbers materially: these are measured with the churn a real load puts around the capture — a state-sized buffer allocated, filled, deserialized and freed between each pair of iterations. Measuring back-to-back captures instead leaves the destination in cache and the allocator warm, and understates what a load actually costs. My first pass at this used the tight-loop form and reported a 16 MiB capture at 1.9 ms where the same capture inside a real load sequence measures 8–9 ms. The tables below are the churn-inclusive figures.

Undo snapshot capture — content_load_state_cb does this on every state load

State	Before	After
4 MiB	0.59 ms	0.36 ms	−39%
16 MiB	2.29 ms	1.89 ms	−17%
64 MiB	39.47 ms	12.17 ms	−69%

The file read barely registers, because #19314's budgeted quantum loop already spreads it across ticks — it never lands in the stall. mmap would cut total load ticks (roughly 6 → 2) but wouldn't move the frame stall.

Against that, the plumbing is significant. The loaded buffer doesn't stay in the handler: it flows to task_load_handler_finished, then to content_load_state_cb, which either free()s it or stores it in undo_save_buf — which is then freed in undo_save_state_cb, freed again in content_reset_savestate_backups, and handed to a task that takes ownership of it. A mapping needs a release-kind flag threaded through all of those, plus rzip detection with fallback, plus a VFS path that can produce a real fd, plus pre-faulting under the tick budget so cold-cache faults don't land unsliced in the deserialize. That's a lot of surface for the smallest of three components.

If the load stall is to come down further, the target is the capture itself, and the honest options are behaviour changes rather than optimizations — skipping the capture when undo-load has never been used in the session, or making it lazy (capture on the first undo request rather than on every load, trading one slow undo for zero cost on every load). Both are worth discussing separately.

Out of scope, unchanged

content_auto_save_state still has an unused-settings warning in non-HAVE_COMPRESSION builds (it's used inside the ifdef). Pre-existing and cosmetic; left alone.