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

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

[Peter Ujfalusi]

From: Yu-Hsuan Hsu <yuhsuan@google.com>

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 <kai.vehmanen@linux.intel.com>
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/soc/sof/pcm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c
index b2071edeaea6..f748d072109a 100644
--- a/sound/soc/sof/pcm.c
+++ b/sound/soc/sof/pcm.c
@@ -62,7 +62,7 @@ void snd_sof_pcm_period_elapsed(struct snd_pcm_substream *substream)
 	 * To avoid sending IPC before the previous IPC is handled, we
 	 * schedule delayed work here to call the snd_pcm_period_elapsed().
 	 */
-	schedule_work(&spcm->stream[substream->stream].period_elapsed_work);
+	queue_work(system_highpri_wq, &spcm->stream[substream->stream].period_elapsed_work);
 }
 EXPORT_SYMBOL(snd_sof_pcm_period_elapsed);
 
-- 
2.55.0

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

[Pierre-Louis Bossart]

On 7/30/26 15:04, Peter Ujfalusi wrote:
> From: Yu-Hsuan Hsu <yuhsuan@google.com>
> 
> 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 <kai.vehmanen@linux.intel.com>
> Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

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);

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...

> ---
>  sound/soc/sof/pcm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c
> index b2071edeaea6..f748d072109a 100644
> --- a/sound/soc/sof/pcm.c
> +++ b/sound/soc/sof/pcm.c
> @@ -62,7 +62,7 @@ void snd_sof_pcm_period_elapsed(struct snd_pcm_substream *substream)
>  	 * To avoid sending IPC before the previous IPC is handled, we
>  	 * schedule delayed work here to call the snd_pcm_period_elapsed().
>  	 */
> -	schedule_work(&spcm->stream[substream->stream].period_elapsed_work);
> +	queue_work(system_highpri_wq, &spcm->stream[substream->stream].period_elapsed_work);
>  }
>  EXPORT_SYMBOL(snd_sof_pcm_period_elapsed);
>  

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

[Péter Ujfalusi]

On 31/07/2026 12:20, Pierre-Louis Bossart wrote:
> On 7/30/26 15:04, Peter Ujfalusi wrote:
>> From: Yu-Hsuan Hsu <yuhsuan@google.com>
>>
>> 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 <kai.vehmanen@linux.intel.com>
>> Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
>> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
>> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
>> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
> 
> 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.

> 
>> ---
>>  sound/soc/sof/pcm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c
>> index b2071edeaea6..f748d072109a 100644
>> --- a/sound/soc/sof/pcm.c
>> +++ b/sound/soc/sof/pcm.c
>> @@ -62,7 +62,7 @@ void snd_sof_pcm_period_elapsed(struct snd_pcm_substream *substream)
>>  	 * To avoid sending IPC before the previous IPC is handled, we
>>  	 * schedule delayed work here to call the snd_pcm_period_elapsed().
>>  	 */
>> -	schedule_work(&spcm->stream[substream->stream].period_elapsed_work);
>> +	queue_work(system_highpri_wq, &spcm->stream[substream->stream].period_elapsed_work);
>>  }
>>  EXPORT_SYMBOL(snd_sof_pcm_period_elapsed);
>>  
> 

-- 
Péter

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

[Pierre-Louis Bossart]

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 <yuhsuan@google.com>
>>>
>>> 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 <kai.vehmanen@linux.intel.com>
>>> Signed-off-by: Yu-Hsuan Hsu <yuhsuan@google.com>
>>> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
>>> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
>>> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
>>
>> 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?

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

[Péter Ujfalusi]

On 31/07/2026 15:19, Pierre-Louis Bossart wrote:
>>> 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.

That is possible, but on the other hand if that is the case then likely
the kernel have been already modified to tailor for one way or the
other.A device where network latency is the priority is likely have no
audio needs.
> 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.

I think this is true for every single device and software, everything is
better if it can be faster but everything cannot be at the same time.
> 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().

In case of NO_PERIOD_WAKEUP the elapsed is not used, this helps in case
when the period elapsed is used and user space uses that.

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

I guess, it could, but what about the graphic, network, touchscreen,
etc? Should they all have the same way to select?

I think audio is a bit special among devices, if there is a slight
scheduling delay it will be noticeable.

Not saying that we should not look for other cases where it would make
noticeable difference, but using high_pri workqueue is not uncommon
among audio drivers where the period elapsed must be handled by a work
for a reason.

-- 
Péter