Re: [PATCH] ASoC: SOF: Use high-priority workqueue for PCM period elapsed

On 7/31/26 11:31, Péter Ujfalusi wrote:
> 
> 
> On 31/07/2026 12:20, Pierre-Louis Bossart wrote:
>> On 7/30/26 15:04, Peter Ujfalusi wrote:
>>> From: Yu-Hsuan Hsu <[email protected]>
>>>
>>> The snd_sof_pcm_period_elapsed function currently schedules work on the
>>> system-wide workqueue. This can lead to potential delays or jitter in
>>> audio processing if the system workqueue is busy with other tasks.
>>>
>>> To improve real-time performance and ensure timely processing of PCM
>>> periods, we can use the system_highpri_wq instead of the default work
>>> queue.
>>>
>>> In performance testing, this change significantly reduced the observed
>>> scheduling delays. For instance, under load(stressapptest -M 15000 -m
>>> 60), the maximum delay dropped from 9ms on the system workqueue to 5ms
>>> on the dedicated high-priority workqueue.
>>>
>>> Suggested-by: Kai Vehmanen <[email protected]>
>>> Signed-off-by: Yu-Hsuan Hsu <[email protected]>
>>> Reviewed-by: Péter Ujfalusi <[email protected]>
>>> Reviewed-by: Kai Vehmanen <[email protected]>
>>> Reviewed-by: Bard Liao <[email protected]>
>>> Signed-off-by: Peter Ujfalusi <[email protected]>
>>
>> Sounds good but should this higher priority queue be used for other
>> things as well?
>>
>> e.g.
>>
>> period-elapsed for compressed streams:
>> schedule_work(&spcm->stream[cstream->direction].period_elapsed_work);
>>
>> and the SoundWire interrupt handling with additional workqueues:
>> schedule_work(&amd_manager->amd_sdw_irq_thread);
>> schedule_work(&amd_manager->amd_sdw_work);
>> schedule_work(&cdns->work);
> 
> we also have:
> sound/soc/sof/core.c:           schedule_work(&sdev->probe_work);
> sound/soc/sof/intel/ptl.c:      schedule_work(&hdev->mic_privacy.work);
> 
>> Not sure what the rules are to define what's high-priority and what's
>> not... It could be that different systems have different requirements...
> 
> I think the 'rule' is that what is time critical and what can tolerate a
> bit of a delay. The PCM period is time critical while the others are not
> that much, that includes the compress elapsed, it is not that real-time
> as the PCM.
> 
> But fair point, I will check if anything else would needs to be higher
> priority than what they are.

My point is that this change isn't bad in itself, but maybe some systems
don't care and have other subsystems (graphics, networking, etc) that
should be given preferred access to the high-priority queue.

Same for the SoundWire workqueues, one could argue that the command
protocol overhead is significant for all the device initialization and
firmware download. Using the higher priority queue could reduce the
initial 'cold latency' for interactive sounds in a busy system.

Going back to the PCM stuff, the period_elapsed stuff is also not that
relevant with timer-based scheduling which relies on snd_pcm_delay().

Could it be that the level of priority should be configurable (Kconfig,
sysfs, kernel parameter) to let distros pick what they need?