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

[Kai Vehmanen]

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