Alsa-Devel Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox