> CPU contention can delay staged capture period notifications while RX > completions continue filling the unread ring. In a two-vCPU VZ guest with > 16 nice-0 CPU workers, the ACK-fixed baseline stopped with ring_capacity > and EPIPE in three runs, after 11.74, 30.77 and 30.33 seconds of audio. > > Route staged capture period work through system_highpri_wq with a common > helper at all ten producers, including ACK errors and self-requeue. Keep > playback and non-staged streams on the normal workqueue. Initialization, > cancellation, buffer geometry and capture accounting remain unchanged. > > With the same kernel, input, geometry and userspace priority, the candidate > completed three 70-second captures and immediate reopens. Its maximum > matched queue-to-start delay was 20.366 ms, versus 108.112 ms in the first > baseline failure. The other baseline failures had pending work without > matching execution, so matched-only statistics do not bound that delay. > > Reader scheduling delays were also present. Both arms passed a separate > nice -10 reader control, and host load varied between runs. These results > support the change for the tested workload without isolating a kernel-only > cause or guaranteeing lossless capture under arbitrary CPU load. > KASAN/lockdep QEMU regressions passed with the unchanged candidate source. > > This follows the staged ACK fix and pending VZ capture support. The > introducing staged-capture patch has no upstream Fixes commit ID yet. > > Link: > https://lore.kernel.org/all/[email protected]/ > Assisted-by: LLM > Signed-off-by: Joonho Lee <[email protected]>
Sashiko has reviewed this patch and found no issues. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
