All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Douglas Anderson
	<dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tomasz Figa <tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Daniel Kurtz <djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Subject: Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages
Date: Tue, 29 Mar 2016 18:02:39 +0100	[thread overview]
Message-ID: <20160329170238.GK6745@arm.com> (raw)
In-Reply-To: <1459146732-15620-1-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote:
> Currently __iommu_dma_alloc_pages assumes that all the IOMMU support
> the granule of PAGE_SIZE. It call alloc_page to try allocating memory
> in the last time. Fortunately the mininum pagesize in all the
> current IOMMU is SZ_4K, so this works well.
> 
> But there may be a case in which the mininum granule of IOMMU may be
> larger than PAGE_SIZE, then it will abort as the IOMMU cann't map the
> discontinuous memory within a granule. For example, the pgsize_bitmap
> of the IOMMU only has SZ_16K while the PAGE_SIZE is SZ_4K, then we
> have to prepare SZ_16K continuous memory at least for each a granule
> iommu mapping.

Did you find a driver/platform that actually needs this? I certainly
think it's possible, but we don't necessarily need to fix it if it's
not broken yet! Just adding a comment would be enough.

Either way, a couple of review comments inline.

> 
> Signed-off-by: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> 
> ---
> v2:
>  -rebase on v4.6-rc1.
>  -add a new patch([1/2] add pgsize_bitmap) here.
> 
>  drivers/iommu/dma-iommu.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 72d6182..75ce71e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -190,11 +190,13 @@ static void __iommu_dma_free_pages(struct page **pages, int count)
>  	kvfree(pages);
>  }
>  
> -static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
> +static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp,
> +					     unsigned long pgsize_bitmap)
>  {
>  	struct page **pages;
>  	unsigned int i = 0, array_size = count * sizeof(*pages);
> -	unsigned int order = MAX_ORDER;
> +	int min_order = get_order(1 << __ffs(pgsize_bitmap));

1UL

> +	int order = MAX_ORDER;
>  
>  	if (array_size <= PAGE_SIZE)
>  		pages = kzalloc(array_size, GFP_KERNEL);
> @@ -213,13 +215,16 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
>  		/*
>  		 * Higher-order allocations are a convenience rather
>  		 * than a necessity, hence using __GFP_NORETRY until
> -		 * falling back to single-page allocations.
> +		 * falling back to min size allocations.
>  		 */
> -		for (order = min_t(unsigned int, order, __fls(count));
> -		     order > 0; order--) {
> -			page = alloc_pages(gfp | __GFP_NORETRY, order);
> +		for (order = min_t(int, order, __fls(count));
> +		     order >= min_order; order--) {
> +			page = alloc_pages((order == min_order) ? gfp :
> +					   gfp | __GFP_NORETRY, order);
>  			if (!page)
>  				continue;
> +			if (!order)
> +				break;

Isn't this handled by the loop condition?

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages
Date: Tue, 29 Mar 2016 18:02:39 +0100	[thread overview]
Message-ID: <20160329170238.GK6745@arm.com> (raw)
In-Reply-To: <1459146732-15620-1-git-send-email-yong.wu@mediatek.com>

On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote:
> Currently __iommu_dma_alloc_pages assumes that all the IOMMU support
> the granule of PAGE_SIZE. It call alloc_page to try allocating memory
> in the last time. Fortunately the mininum pagesize in all the
> current IOMMU is SZ_4K, so this works well.
> 
> But there may be a case in which the mininum granule of IOMMU may be
> larger than PAGE_SIZE, then it will abort as the IOMMU cann't map the
> discontinuous memory within a granule. For example, the pgsize_bitmap
> of the IOMMU only has SZ_16K while the PAGE_SIZE is SZ_4K, then we
> have to prepare SZ_16K continuous memory at least for each a granule
> iommu mapping.

Did you find a driver/platform that actually needs this? I certainly
think it's possible, but we don't necessarily need to fix it if it's
not broken yet! Just adding a comment would be enough.

Either way, a couple of review comments inline.

> 
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> 
> ---
> v2:
>  -rebase on v4.6-rc1.
>  -add a new patch([1/2] add pgsize_bitmap) here.
> 
>  drivers/iommu/dma-iommu.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 72d6182..75ce71e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -190,11 +190,13 @@ static void __iommu_dma_free_pages(struct page **pages, int count)
>  	kvfree(pages);
>  }
>  
> -static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
> +static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp,
> +					     unsigned long pgsize_bitmap)
>  {
>  	struct page **pages;
>  	unsigned int i = 0, array_size = count * sizeof(*pages);
> -	unsigned int order = MAX_ORDER;
> +	int min_order = get_order(1 << __ffs(pgsize_bitmap));

1UL

> +	int order = MAX_ORDER;
>  
>  	if (array_size <= PAGE_SIZE)
>  		pages = kzalloc(array_size, GFP_KERNEL);
> @@ -213,13 +215,16 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
>  		/*
>  		 * Higher-order allocations are a convenience rather
>  		 * than a necessity, hence using __GFP_NORETRY until
> -		 * falling back to single-page allocations.
> +		 * falling back to min size allocations.
>  		 */
> -		for (order = min_t(unsigned int, order, __fls(count));
> -		     order > 0; order--) {
> -			page = alloc_pages(gfp | __GFP_NORETRY, order);
> +		for (order = min_t(int, order, __fls(count));
> +		     order >= min_order; order--) {
> +			page = alloc_pages((order == min_order) ? gfp :
> +					   gfp | __GFP_NORETRY, order);
>  			if (!page)
>  				continue;
> +			if (!order)
> +				break;

Isn't this handled by the loop condition?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Yong Wu <yong.wu@mediatek.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Douglas Anderson <dianders@chromium.org>,
	Daniel Kurtz <djkurtz@google.com>, Tomasz Figa <tfiga@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Lucas Stach <l.stach@pengutronix.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages
Date: Tue, 29 Mar 2016 18:02:39 +0100	[thread overview]
Message-ID: <20160329170238.GK6745@arm.com> (raw)
In-Reply-To: <1459146732-15620-1-git-send-email-yong.wu@mediatek.com>

On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote:
> Currently __iommu_dma_alloc_pages assumes that all the IOMMU support
> the granule of PAGE_SIZE. It call alloc_page to try allocating memory
> in the last time. Fortunately the mininum pagesize in all the
> current IOMMU is SZ_4K, so this works well.
> 
> But there may be a case in which the mininum granule of IOMMU may be
> larger than PAGE_SIZE, then it will abort as the IOMMU cann't map the
> discontinuous memory within a granule. For example, the pgsize_bitmap
> of the IOMMU only has SZ_16K while the PAGE_SIZE is SZ_4K, then we
> have to prepare SZ_16K continuous memory at least for each a granule
> iommu mapping.

Did you find a driver/platform that actually needs this? I certainly
think it's possible, but we don't necessarily need to fix it if it's
not broken yet! Just adding a comment would be enough.

Either way, a couple of review comments inline.

> 
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> 
> ---
> v2:
>  -rebase on v4.6-rc1.
>  -add a new patch([1/2] add pgsize_bitmap) here.
> 
>  drivers/iommu/dma-iommu.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 72d6182..75ce71e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -190,11 +190,13 @@ static void __iommu_dma_free_pages(struct page **pages, int count)
>  	kvfree(pages);
>  }
>  
> -static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
> +static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp,
> +					     unsigned long pgsize_bitmap)
>  {
>  	struct page **pages;
>  	unsigned int i = 0, array_size = count * sizeof(*pages);
> -	unsigned int order = MAX_ORDER;
> +	int min_order = get_order(1 << __ffs(pgsize_bitmap));

1UL

> +	int order = MAX_ORDER;
>  
>  	if (array_size <= PAGE_SIZE)
>  		pages = kzalloc(array_size, GFP_KERNEL);
> @@ -213,13 +215,16 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, gfp_t gfp)
>  		/*
>  		 * Higher-order allocations are a convenience rather
>  		 * than a necessity, hence using __GFP_NORETRY until
> -		 * falling back to single-page allocations.
> +		 * falling back to min size allocations.
>  		 */
> -		for (order = min_t(unsigned int, order, __fls(count));
> -		     order > 0; order--) {
> -			page = alloc_pages(gfp | __GFP_NORETRY, order);
> +		for (order = min_t(int, order, __fls(count));
> +		     order >= min_order; order--) {
> +			page = alloc_pages((order == min_order) ? gfp :
> +					   gfp | __GFP_NORETRY, order);
>  			if (!page)
>  				continue;
> +			if (!order)
> +				break;

Isn't this handled by the loop condition?

Will

  parent reply	other threads:[~2016-03-29 17:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-28  6:32 [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages Yong Wu
2016-03-28  6:32 ` Yong Wu
2016-03-28  6:32 ` Yong Wu
     [not found] ` <1459146732-15620-1-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-03-28  6:32   ` [PATCH v2 2/2] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support Yong Wu
2016-03-28  6:32     ` Yong Wu
2016-03-28  6:32     ` Yong Wu
2016-03-29 17:02   ` Will Deacon [this message]
2016-03-29 17:02     ` [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages Will Deacon
2016-03-29 17:02     ` Will Deacon
     [not found]     ` <20160329170238.GK6745-5wv7dgnIgG8@public.gmane.org>
2016-04-05 17:03       ` Doug Anderson
2016-04-05 17:03         ` Doug Anderson
2016-04-05 17:03         ` Doug Anderson
2016-04-08 13:07         ` Will Deacon
2016-04-08 13:07           ` Will Deacon
     [not found]           ` <20160408130733.GD23750-5wv7dgnIgG8@public.gmane.org>
2016-04-08 16:50             ` Doug Anderson
2016-04-08 16:50               ` Doug Anderson
2016-04-08 16:50               ` Doug Anderson
     [not found]               ` <CAD=FV=VbekVUHW3=d0icSgUO1M-1cccwCAZ+s=YSzOtEveCQag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-08 17:30                 ` Will Deacon
2016-04-08 17:30                   ` Will Deacon
2016-04-08 17:30                   ` Will Deacon
     [not found]                   ` <20160408173002.GJ23750-5wv7dgnIgG8@public.gmane.org>
2016-04-08 17:34                     ` Doug Anderson
2016-04-08 17:34                       ` Doug Anderson
2016-04-08 17:34                       ` Doug Anderson
     [not found]                       ` <CAD=FV=XbL6gbdmX62Q3QJQ6R-rC7cCd44RLPgK3kvhAC49BJjA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-11  7:40                         ` Yong Wu
2016-04-11  7:40                           ` Yong Wu
2016-04-11  7:40                           ` Yong Wu

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=20160329170238.GK6745@arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    /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.