All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>, 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, "Arava,
	Jairaj" <jairaj.arava@intel.com>
Subject: Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case
Date: Fri, 16 Feb 2024 15:43:09 +0100	[thread overview]
Message-ID: <87zfw0h3lu.wl-tiwai@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2402161246520.14041@eliteleevi.tm.intel.com>

On Fri, 16 Feb 2024 13:19:54 +0100,
Kai Vehmanen wrote:
> 
> 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().

OK, then how about the one like below?

This changes:
- Back to __GFP_NORETRY as default
- Use __GFP_RETRY_MAYFAIL for SNDRV_DMA_TYPE_NONCONTIG with IOMMU;
  this should cover the commit a61c7d88d38c
- Also use __GFP_RETRY_MAYFAIL for the SG-fallback allocations of the
  minimal order, just like IOMMU allocator does.

This should be less destructive, while still allowing more aggressive
allocations for SG buffers.


thanks,

Takashi

--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -21,9 +21,13 @@
 
 #define DEFAULT_GFP \
 	(GFP_KERNEL | \
-	 __GFP_RETRY_MAYFAIL | /* don't trigger OOM-killer */ \
+	 __GFP_NORETRY | /* don't trigger OOM-killer */ \
 	 __GFP_NOWARN)   /* no stack trace print - this call is non-critical */
 
+/* GFP flags to be used for low order pages, allowing reclaim and compaction */
+#define DEFAULT_GFP_RETRY \
+	(GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN)
+
 static const struct snd_malloc_ops *snd_dma_get_ops(struct snd_dma_buffer *dmab);
 
 #ifdef CONFIG_SND_DMA_SGBUF
@@ -281,7 +285,11 @@ static void *do_alloc_pages(struct device *dev, size_t size, dma_addr_t *addr,
 			    bool wc)
 {
 	void *p;
-	gfp_t gfp = GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN;
+	gfp_t gfp = DEFAULT_GFP;
+
+	/* allow reclaim and compaction for low order pages */
+	if (size <= PAGE_SIZE)
+		gfp = DEFAULT_GFP_RETRY;
 
  again:
 	p = alloc_pages_exact(size, gfp);
@@ -539,14 +547,18 @@ static const struct snd_malloc_ops snd_dma_wc_ops = {
 static void *snd_dma_noncontig_alloc(struct snd_dma_buffer *dmab, size_t size)
 {
 	struct sg_table *sgt;
+	gfp_t gfp = DEFAULT_GFP;
 	void *p;
 
 #ifdef CONFIG_SND_DMA_SGBUF
 	if (cpu_feature_enabled(X86_FEATURE_XENPV))
 		return snd_dma_sg_fallback_alloc(dmab, size);
+	/* with IOMMU, it's safe to pass __GFP_RETRY_MAYFAIL with high order */
+	if (get_dma_ops(dmab->dev.dev))
+		gfp = DEFAULT_GFP_RETRY;
 #endif
 	sgt = dma_alloc_noncontiguous(dmab->dev.dev, size, dmab->dev.dir,
-				      DEFAULT_GFP, 0);
+				      gfp, 0);
 #ifdef CONFIG_SND_DMA_SGBUF
 	if (!sgt && !get_dma_ops(dmab->dev.dev))
 		return snd_dma_sg_fallback_alloc(dmab, size);

  reply	other threads:[~2024-02-16 14:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15  0:07 [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case Karthikeyan Ramasubramanian
2024-02-15  3:45 ` Hillf Danton
2024-02-15  8:40   ` Takashi Iwai
2024-02-15 16:07     ` Sven van Ashbrook
2024-02-15 17:03       ` Takashi Iwai
2024-02-15 19:32         ` Karthikeyan Ramasubramanian
2024-02-16  7:47           ` Takashi Iwai
2024-02-16  4:34         ` Hillf Danton
2024-02-16  8:35           ` Takashi Iwai
2024-02-16 10:18             ` Takashi Iwai
2024-02-16 12:19               ` Kai Vehmanen
2024-02-16 14:43                 ` Takashi Iwai [this message]
2024-02-16 16:22                   ` Sven van Ashbrook
2024-02-19 11:19                     ` Takashi Iwai
2024-02-21 18:09                       ` Karthikeyan Ramasubramanian
2024-02-16 10:51             ` Hillf Danton
2024-02-19 11:36 ` Stall at page allocations with __GFP_RETRY_MAYFAIL (Re: [PATCH v1] ALSA: memalloc: Fix indefinite hang in non-iommu case) Takashi Iwai
2024-02-19 11:40   ` Vlastimil Babka
2024-02-20 15:52     ` Sven van Ashbrook
2024-02-21  9:21       ` Takashi Iwai
2024-02-21 15:37         ` Sven van Ashbrook
2024-02-21  9:58       ` Vlastimil Babka
2024-02-21 15:40         ` Sven van Ashbrook
2024-02-21 11:43       ` [PATCH] mm, vmscan: prevent infinite loop for costly GFP_NOIO | __GFP_RETRY_MAYFAIL allocations Vlastimil Babka
2024-02-21 15:52         ` Sven van Ashbrook
2024-02-22 16:43           ` Karthikeyan Ramasubramanian
2024-02-26 16:09         ` Sven van Ashbrook
2024-02-26 16:45           ` Vlastimil Babka
2024-02-28 19:33         ` Karthikeyan Ramasubramanian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfw0h3lu.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=bgeffon@google.com \
    --cc=hdanton@sina.com \
    --cc=jairaj.arava@intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=kramasub@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=svenva@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.