From: Robin Murphy <robin.murphy@arm.com>
To: Qian Cai <cai@gmx.us>, hch@lst.de, m.szyprowski@samsung.com
Cc: netdev@vger.kernel.org, linuxarm@huawei.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
yisen.zhuang@huawei.com
Subject: Re: [PATCH] dma-debug: Kconfig for PREALLOC_DMA_DEBUG_ENTRIES
Date: Fri, 30 Nov 2018 19:39:50 +0000 [thread overview]
Message-ID: <b22d2ad6-2638-96d7-1df2-24701589202f@arm.com> (raw)
In-Reply-To: <20181130175449.2625-1-cai@gmx.us>
On 30/11/2018 17:54, Qian Cai wrote:
> The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
> so it could trigger "DMA-API: debugging out of memory - disabling".
>
> hnae_get_handle [1]
> hnae_init_queue
> hnae_init_ring
> hnae_alloc_buffers [2]
> debug_dma_map_page
> dma_entry_alloc
>
> [1] for (i = 0; i < handle->q_num; i++)
> [2] for (i = 0; i < ring->desc_num; i++)
>
> On this Huawei TaiShan 2280 aarch64 server, it has reached the limit
> already,
>
> 4 (ports) x 16 (handles) x 1024 (rings) = 65536
>
> Added a Kconfig entry for PREALLOC_DMA_DEBUG_ENTRIES, so make it easier
> for users to deal with special cases like this.
>
> Signed-off-by: Qian Cai <cai@gmx.us>
> ---
> kernel/dma/debug.c | 9 ++-------
> lib/Kconfig.debug | 9 +++++++++
> 2 files changed, 11 insertions(+), 7 deletions(-)
Oh, right, the arch overrides actually got cleaned up already. I'd
forgotten that...
> diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
> index 231ca4628062..3752fb23f72f 100644
> --- a/kernel/dma/debug.c
> +++ b/kernel/dma/debug.c
> @@ -41,11 +41,6 @@
> #define HASH_FN_SHIFT 13
> #define HASH_FN_MASK (HASH_SIZE - 1)
>
> -/* allow architectures to override this if absolutely required */
> -#ifndef PREALLOC_DMA_DEBUG_ENTRIES
> -#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
> -#endif
> -
> enum {
> dma_debug_single,
> dma_debug_page,
> @@ -132,7 +127,7 @@ static u32 min_free_entries;
> static u32 nr_total_entries;
>
> /* number of preallocated entries requested by kernel cmdline */
> -static u32 nr_prealloc_entries = PREALLOC_DMA_DEBUG_ENTRIES;
> +static u32 nr_prealloc_entries = CONFIG_PREALLOC_DMA_DEBUG_ENTRIES;
>
> /* debugfs dentry's for the stuff above */
> static struct dentry *dma_debug_dent __read_mostly;
> @@ -1063,7 +1058,7 @@ static __init int dma_debug_entries_cmdline(char *str)
> if (!str)
> return -EINVAL;
> if (!get_option(&str, &nr_prealloc_entries))
> - nr_prealloc_entries = PREALLOC_DMA_DEBUG_ENTRIES;
> + nr_prealloc_entries = CONFIG_PREALLOC_DMA_DEBUG_ENTRIES;
> return 0;
> }
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 1af29b8224fd..2c281edcb5ad 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1659,6 +1659,15 @@ config DMA_API_DEBUG
>
> If unsure, say N.
>
> +config PREALLOC_DMA_DEBUG_ENTRIES
> + int "Preallocated DMA-API debugging entries"
> + depends on DMA_API_DEBUG
> + default 65536
I was assuming the point was to also add something like
default 131072 if HNS_ENET
so that DMA debug doesn't require too much thought from the user. If
they still have to notice the overflow message and empirically figure
out a value that does work, rebuilding the kernel each time is far less
convenient than simply adding "dma_debug_entries=..." to their kernel
command line and rebooting, which they can do today. If they do already
know up-front that the default will need overriding and what the
appropriate value is, then the command line still seems seems just as
convenient.
Robin.
> + help
> + The number of preallocated entries for DMA-API debugging code. One
> + entry is required per DMA-API allocation. Increase this if the DMA-API
> + debugging code disables itself because the default is too low.
> +
> config DMA_API_DEBUG_SG
> bool "Debug DMA scatter-gather usage"
> default y
>
next prev parent reply other threads:[~2018-11-30 19:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 17:54 Qian Cai
2018-11-30 19:39 ` Robin Murphy [this message]
2018-12-01 16:36 ` Christoph Hellwig
2018-12-03 11:56 ` John Garry
2018-12-03 17:33 ` Christoph Hellwig
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=b22d2ad6-2638-96d7-1df2-24701589202f@arm.com \
--to=robin.murphy@arm.com \
--cc=cai@gmx.us \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=m.szyprowski@samsung.com \
--cc=netdev@vger.kernel.org \
--cc=yisen.zhuang@huawei.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
all inboxes | Powered by JetHome®