All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	David Rientjes <rientjes@google.com>
Cc: linux-rpi-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
Date: Wed, 8 Jul 2020 18:14:39 -0500	[thread overview]
Message-ID: <a32e1017-4724-7cd8-0ba9-daddfaad1f44@arm.com> (raw)
In-Reply-To: <20200708164936.9340-1-nsaenzjulienne@suse.de>

Hi,

On 7/8/20 11:49 AM, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. So stop using it.
> 
> Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp mask")
> Reported-by: Jeremy Linton <jeremy.linton@arm.com>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---

With this patch and 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2226971.html 
the machine appears to be working fine with/without CMA and in both 
DT/ACPI mode.

The JBOD/etc I was having problems with are working fine, and the rtlsdr 
seems to be working better now too (its still not perfect, but that is 
likely another issue).

so:

tested-by: Jeremy Linton <jeremy.linton@arm.com>

thanks!


> 
> An more costly alternative would be adding an option to
> dma_alloc_from_contiguous() so it fails when the allocation doesn't fall
> in a specific zone.
> 
>   kernel/dma/pool.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 8cfa01243ed2..4bc1c46ae6ef 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -6,7 +6,6 @@
>   #include <linux/debugfs.h>
>   #include <linux/dma-direct.h>
>   #include <linux/dma-noncoherent.h>
> -#include <linux/dma-contiguous.h>
>   #include <linux/init.h>
>   #include <linux/genalloc.h>
>   #include <linux/set_memory.h>
> @@ -69,12 +68,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>   
>   	do {
>   		pool_size = 1 << (PAGE_SHIFT + order);
> -
> -		if (dev_get_cma_area(NULL))
> -			page = dma_alloc_from_contiguous(NULL, 1 << order,
> -							 order, false);
> -		else
> -			page = alloc_pages(gfp, order);
> +		page = alloc_pages(gfp, order);
>   	} while (!page && order-- > 0);
>   	if (!page)
>   		goto out;
> @@ -118,8 +112,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>   	dma_common_free_remap(addr, pool_size);
>   #endif
>   free_page: __maybe_unused
> -	if (!dma_release_from_contiguous(NULL, page, 1 << order))
> -		__free_pages(page, order);
> +	__free_pages(page, order);
>   out:
>   	return ret;
>   }
> 


WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Linton <jeremy.linton@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	David Rientjes <rientjes@google.com>
Cc: iommu@lists.linux-foundation.org,
	linux-rpi-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
Date: Wed, 8 Jul 2020 18:14:39 -0500	[thread overview]
Message-ID: <a32e1017-4724-7cd8-0ba9-daddfaad1f44@arm.com> (raw)
In-Reply-To: <20200708164936.9340-1-nsaenzjulienne@suse.de>

Hi,

On 7/8/20 11:49 AM, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. So stop using it.
> 
> Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp mask")
> Reported-by: Jeremy Linton <jeremy.linton@arm.com>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---

With this patch and 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2226971.html 
the machine appears to be working fine with/without CMA and in both 
DT/ACPI mode.

The JBOD/etc I was having problems with are working fine, and the rtlsdr 
seems to be working better now too (its still not perfect, but that is 
likely another issue).

so:

tested-by: Jeremy Linton <jeremy.linton@arm.com>

thanks!


> 
> An more costly alternative would be adding an option to
> dma_alloc_from_contiguous() so it fails when the allocation doesn't fall
> in a specific zone.
> 
>   kernel/dma/pool.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 8cfa01243ed2..4bc1c46ae6ef 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -6,7 +6,6 @@
>   #include <linux/debugfs.h>
>   #include <linux/dma-direct.h>
>   #include <linux/dma-noncoherent.h>
> -#include <linux/dma-contiguous.h>
>   #include <linux/init.h>
>   #include <linux/genalloc.h>
>   #include <linux/set_memory.h>
> @@ -69,12 +68,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>   
>   	do {
>   		pool_size = 1 << (PAGE_SHIFT + order);
> -
> -		if (dev_get_cma_area(NULL))
> -			page = dma_alloc_from_contiguous(NULL, 1 << order,
> -							 order, false);
> -		else
> -			page = alloc_pages(gfp, order);
> +		page = alloc_pages(gfp, order);
>   	} while (!page && order-- > 0);
>   	if (!page)
>   		goto out;
> @@ -118,8 +112,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
>   	dma_common_free_remap(addr, pool_size);
>   #endif
>   free_page: __maybe_unused
> -	if (!dma_release_from_contiguous(NULL, page, 1 << order))
> -		__free_pages(page, order);
> +	__free_pages(page, order);
>   out:
>   	return ret;
>   }
> 

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2020-07-08 23:14 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 16:49 [PATCH] dma-pool: Do not allocate pool memory from CMA Nicolas Saenz Julienne
2020-07-08 16:49 ` Nicolas Saenz Julienne
2020-07-08 16:58 ` Christoph Hellwig
2020-07-08 16:58   ` Christoph Hellwig
2020-07-08 23:14 ` Jeremy Linton [this message]
2020-07-08 23:14   ` Jeremy Linton
2020-07-09 21:47 ` David Rientjes
2020-07-09 21:47   ` David Rientjes via iommu
2020-07-21  7:21 ` Amit Pundir
2020-07-21  7:21   ` Amit Pundir
2020-07-21  8:39   ` Nicolas Saenz Julienne
2020-07-21  8:39     ` Nicolas Saenz Julienne
2020-07-21  8:54     ` Amit Pundir
2020-07-21  8:54       ` Amit Pundir
2020-07-21 11:15       ` Nicolas Saenz Julienne
2020-07-21 11:15         ` Nicolas Saenz Julienne
2020-07-21 11:28         ` Christoph Hellwig
2020-07-21 11:28           ` Christoph Hellwig
2020-07-21 11:37           ` Nicolas Saenz Julienne
2020-07-21 11:37             ` Nicolas Saenz Julienne
2020-07-21 12:16             ` Amit Pundir
2020-07-21 12:16               ` Amit Pundir
2020-07-21 12:15         ` Amit Pundir
2020-07-21 12:15           ` Amit Pundir
2020-07-21 12:45           ` Nicolas Saenz Julienne
2020-07-21 12:45             ` Nicolas Saenz Julienne
2020-07-21 15:22             ` Amit Pundir
2020-07-21 15:22               ` Amit Pundir
2020-07-21 16:27               ` Nicolas Saenz Julienne
2020-07-21 16:27                 ` Nicolas Saenz Julienne
2020-07-23  5:14                 ` Amit Pundir
2020-07-23  5:14                   ` Amit Pundir
2020-07-24  9:36                   ` Nicolas Saenz Julienne
2020-07-24  9:36                     ` Nicolas Saenz Julienne
2020-07-24 11:06                     ` Amit Pundir
2020-07-24 11:06                       ` Amit Pundir
2020-07-24 13:41                       ` Christoph Hellwig
2020-07-24 13:41                         ` Christoph Hellwig
2020-07-24 16:19                         ` Amit Pundir
2020-07-24 16:19                           ` Amit Pundir
2020-07-24 16:27                           ` Christoph Hellwig
2020-07-24 16:27                             ` Christoph Hellwig
2020-07-27 17:56                         ` Nicolas Saenz Julienne
2020-07-27 17:56                           ` Nicolas Saenz Julienne
2020-07-28  9:13                           ` Christoph Hellwig
2020-07-28  9:13                             ` Christoph Hellwig
2020-07-28  9:30                             ` Nicolas Saenz Julienne
2020-07-28  9:30                               ` Nicolas Saenz Julienne
2020-07-28 10:09                               ` Christoph Hellwig
2020-07-28 10:09                                 ` Christoph Hellwig
2020-07-31  1:10                                 ` Nathan Chancellor
2020-07-31  1:10                                   ` Nathan Chancellor
2020-07-31  7:19                                   ` Amit Pundir
2020-07-31  7:19                                     ` Amit Pundir
2020-07-31 10:09                                   ` Nicolas Saenz Julienne
2020-07-31 10:09                                     ` Nicolas Saenz Julienne

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=a32e1017-4724-7cd8-0ba9-daddfaad1f44@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=m.szyprowski@samsung.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=rientjes@google.com \
    --cc=robin.murphy@arm.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.