Re: [PATCH] ALSA: hda: Reduce udelay() at SKL+ position reporting

[Jens Axboe <axboe@kernel.dk>]

On 9/10/21 8:10 AM, Takashi Iwai wrote:
> The position reporting on Intel Skylake and later chips via
> azx_get_pos_skl() contains a udelay(20) call for the capture streams.
> A call for this alone doesn't sound too harmful.  However, as the
> pointer PCM ops is one of the hottest path in the PCM operations --
> especially for the timer-scheduled operations like PulseAudio -- such
> a delay hogs CPU usage significantly in the total performance.
> 
> The function there was taken from the original code in ASoC SST
> Skylake driver blindly.  The udelay() is a workaround for the case
> where the reported position is behind the period boundary at the
> timing triggered from interrupts; applications often expect that the
> full data is available for the whole period when returned (and also
> that's the definition of the ALSA PCM period).
> 
> OTOH, HD-audio (legacy) driver has already some workarounds for the
> delayed position reporting due to its relatively large FIFO, such as
> the BDL position adjustment and the delayed period-elapsed call in the
> work.  That said, the udelay() is almost superfluous for HD-audio
> driver unlike SST, and we can drop the udelay().
> 
> Though, the current code doesn't guarantee the full period readiness
> as mentioned in the above, but rather it checks the wallclock and
> detects the unexpected jump.  That's one missing piece, and the drop
> of udelay() needs a bit more sanity checks for the delayed handling.
> 
> This patch implements those: the drop of udelay() call in
> azx_get_pos_skl() and the more proper check of hwptr in
> azx_position_ok().  The latter change is applied only for the case
> where the stream is running in the normal mode without
> no_period_wakeup flag.  When no_period_wakeup is set, it essentially
> ignores the period handling and rather concentrates only on the
> current position; which implies that we don't need to care about the
> period boundary at all.

I tested this on top of 5.15-rc1, and it seems like a massive
improvement. No longer have stalled or slowed down nestopia, seems
smooth all the time. I'll report back in a few days, just in case.

-- 
Jens Axboe