Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case

Kai Vehmanen
2024-02-16T12:20:10Z

Hi,

On Fri, 16 Feb 2024, Takashi Iwai wrote:

> On Fri, 16 Feb 2024 09:35:32 +0100, Takashi Iwai wrote:
> > The fact that we have to drop __GFP_RETRY_MAYFAIL indicates that the
> > handling there doesn't suffice -- at least for the audio operation.
>
> Reconsidering on this again, I wonder keeping __GFP_RETRY_MAYFAIL
> makes sense. We did have __GFP_NORETRY for avoiding OOM-killer.
> But it's been over ages, and the memory allocation core became smart
> enough.
>
> The side-effect of __GFP_RETRY_MAYFAIL is that the page reclaim and
> compaction happens even for high-order allocations, and that must be

for the original problem that led to "ALSA: memalloc: use
__GFP_RETRY_MAYFAIL for DMA mem allocs", reclaim for low-order case
would be enough. I.e. the case was:

> OTOH, a slight concern with the drop of __GFP_RETRY_MAYFAIL is whether
> allowing OOM-killer for low order allocations is acceptable or not.
>
> There are two patterns of calling allocators:
[..]
> 3. SNDRV_DMA_TYPE_NONCONTIG for large size:
> this is called often, once per stream open, since the driver
> doesn't keep the buffer.

So with SOF we have additional case where we do an allocation for the DSP
firmware (snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_SG, ...)) and this is
called at system resume. With s/__GPF_RETRY_MAYFAIL/__GFP_NORETRY/, these
allocations failed (on a iommu enabled Chromebook) at system resume in a
case where system was not really running out of memory (reclaim was
possible). A failed allocation means there's no audio in the system after
resume, so we want to try harder.

But yeah, I think the proposed handling for (3) category would work. If
needed, we can further specialize the DSP firmware case with some hint
to snd_dma_alloc_pages().

Br, Kai