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: alsa-devel@alsa-project.org, peter.ujfalusi@linux.intel.com,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH] ALSA: memalloc: use __GFP_RETRY_MAYFAIL for DMA mem allocs
Date: Mon, 26 Sep 2022 08:57:48 +0200	[thread overview]
Message-ID: <877d1q4o7n.wl-tiwai@suse.de> (raw)
In-Reply-To: <20220923153501.3326041-1-kai.vehmanen@linux.intel.com>

On Fri, 23 Sep 2022 17:35:01 +0200,
Kai Vehmanen wrote:
> 
> Use __GFP_RETRY_MAYFAIL instead of __GFP__NORETRY in
> snd_dma_dev_alloc(), snd_dma_wc_alloc() and friends, to allocate pages
> for device memory. The MAYFAIL flag retains the semantics of not
> triggering the OOM killer, but lowers the risk of alloc failure.
> 
> MAYFAIL flag was added in commit dcda9b04713c3 ("mm, tree wide: replace
> __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic").
> 
> This change addresses recurring failures with SOF audio driver in test
> cases where a system suspend-resume stress test is run, combined with an
> active high memory-load use-case. The failure typically shows up as:
> 
> [ 379.480229] sof-audio-pci-intel-tgl 0000:00:1f.3: booting DSP firmware
> [ 379.484803] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12
> [ 379.484810] sof-audio-pci-intel-tgl 0000:00:1f.3: error: dma prepare for ICCMAX stream failed
> 
> Multiple fixes to reduce the memory usage of DSP boot have been
> identified in SOF driver, but even with those fixes, debug on affected
> systems has shown that even a single page alloc may fail with
> __GFP_NORETRY. When this occurs, system is under significant load on
> physical memory, but a lot of reclaimable pages are available, so the
> system has not run out of memory. With __GFP_RETRY_MAYFAIL, the errors
> are not hit in these stress tests.
> 
> The alloc failure is severe as audio capability is completely lost if
> alloc failure is hit at system resume.
> 
> An alternative solution was considered where the resources for DSP boot
> would be kept allocated until driver is unbound. This would avoid the
> allocation failure, but consume memory that is only needed temporarily
> at probe and resume time. It seems better to not hang on to the memory,
> but rather work a bit harder for allocating the pages at resume.
> 
> BugLink: https://github.com/thesofproject/linux/issues/3844
> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Thanks, applied.


Takashi

      reply	other threads:[~2022-09-26  6:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23 15:35 [PATCH] ALSA: memalloc: use __GFP_RETRY_MAYFAIL for DMA mem allocs Kai Vehmanen
2022-09-26  6:57 ` Takashi Iwai [this message]

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=877d1q4o7n.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    /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.