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
next prev 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: linkBe 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.