Messages in this thread | | | Date | Fri, 16 Feb 2024 14:19:54 +0200 (EET) | From | Kai Vehmanen <> | Subject | Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case |
| |
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
| |