Re: [RFC PATCH 2/2] ALSA: virtio: prioritize staged capture period work

[sashiko-bot@kernel.org]

> 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/rfc-v2-vz-capture-compat-1.b9ab4c1540dc4691@gmail.com/
> Assisted-by: LLM
> Signed-off-by: Joonho Lee <mynameisjune111@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/rfc-virtio-snd-capture-followups-0.f2737c95c12e45b4@gmail.com?part=2