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

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

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