Received-SPF: pass (google.com: domain of linux-kernel+bounces-68563-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 16 Feb 2024 14:19:54 +0200 (EET)
From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
cc: Hillf Danton <hdanton@sina.com>, Sven van Ashbrook <svenva@chromium.org>, 
    Karthikeyan Ramasubramanian <kramasub@chromium.org>, 
    LKML <linux-kernel@vger.kernel.org>, Brian Geffon <bgeffon@google.com>, 
    linux-sound@vger.kernel.org, Kai Vehmanen <kai.vehmanen@linux.intel.com>, 
    "Arava, Jairaj" <jairaj.arava@intel.com>
Subject: Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu
 case
In-Reply-To: <87frxsiueo.wl-tiwai@suse.de>
Message-ID: <alpine.DEB.2.22.394.2402161246520.14041@eliteleevi.tm.intel.com>
References: <20240214170720.v1.1.Ic3de2566a7fd3de8501b2f18afa9f94eadb2df0a@changeid> <20240215034528.240-1-hdanton@sina.com> <87h6iaf7di.wl-tiwai@suse.de> <CAG-rBigFG-U-sKY77CvzghGzs+1Xm3YXzBF6N4ti0+h6UdAb8Q@mail.gmail.com> <875xypk6d6.wl-tiwai@suse.de>
 <20240216043426.1218-1-hdanton@sina.com> <87plwwiz6z.wl-tiwai@suse.de> <87frxsiueo.wl-tiwai@suse.de>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7 02160 Espoo
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

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