All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	Peter Hurley <peter@hurleysoftware.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Don Dutile <ddutile@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>, Yinghai Lu <yinghai@kernel.org>,
	x86@kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH 1/2] x86: don't unnecessarily call dma_alloc_from_contiguous()
Date: Sun, 28 Sep 2014 15:45:25 -0500	[thread overview]
Message-ID: <20140928154525.76cc5464@as> (raw)
In-Reply-To: <1411919524-3666-1-git-send-email-akinobu.mita@gmail.com>

On Mon, 29 Sep 2014 00:52:03 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:

> If CONFIG_DMA_CMA is enabled, dma_generic_alloc_coherent() tries to
> allocate memory region by dma_alloc_from_contiguous() before trying to
> use alloc_pages().
> 
> This wastes CMA region by small DMA-coherent buffers which can be
> allocated by alloc_pages().  And it also causes performance degradation,
> as this is trying to drive _all_ dma mapping allocations through a
> _very_ small window, reported by Peter Hurley.
> 
> This fixes it by trying to allocate by alloc_pages() first in
> dma_generic_alloc_coherent() as dma_alloc_from_contiguous should be
> called only for huge allocation.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Reported-by: Peter Hurley <peter@hurleysoftware.com>
> Cc: Peter Hurley <peter@hurleysoftware.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Don Dutile <ddutile@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> Cc: x86@kernel.org
> Cc: iommu@lists.linux-foundation.org
> ---
>  arch/x86/kernel/pci-dma.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index a25e202..0402266 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -99,20 +99,20 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t size,
>  
>  	flag &= ~__GFP_ZERO;
>  again:
> -	page = NULL;
> +	page = alloc_pages_node(dev_to_node(dev), flag | __GFP_NOWARN,
> +				get_order(size));

Only try small allocs here, like when order < PAGE_ALLOC_COSTLY_ORDER ?

>  	/* CMA can be used only in the context which permits sleeping */
> -	if (flag & __GFP_WAIT) {
> +	if (!page && (flag & __GFP_WAIT)) {
>  		page = dma_alloc_from_contiguous(dev, count, get_order(size));
>  		if (page && page_to_phys(page) + size > dma_mask) {
>  			dma_release_from_contiguous(dev, page, count);
>  			page = NULL;
>  		}
>  	}
> -	/* fallback */
> -	if (!page)
> -		page = alloc_pages_node(dev_to_node(dev), flag, get_order(size));

(I forgot to add this in my first reply). I think it should try for a
small alloc without CMA first, then try CMA, and then this final
fallback for larger allocs.

> -	if (!page)
> +	if (!page) {
> +		warn_alloc_failed(flag, get_order(size), NULL);
>  		return NULL;
> +	}
>  
>  	addr = page_to_phys(page);
>  	if (addr + size > dma_mask) {

  parent reply	other threads:[~2014-09-28 20:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 15:52 [PATCH 1/2] x86: don't unnecessarily call dma_alloc_from_contiguous() Akinobu Mita
2014-09-28 15:52 ` Akinobu Mita
     [not found] ` <1411919524-3666-1-git-send-email-akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-09-28 15:52   ` [PATCH 2/2] intel-iommu: " Akinobu Mita
2014-09-28 15:52     ` Akinobu Mita
2014-09-28 20:41 ` [PATCH 1/2] x86: " Chuck Ebbert
2014-09-28 20:45 ` Chuck Ebbert [this message]
2014-09-29 13:21   ` Akinobu Mita
2014-09-29 13:21     ` Akinobu Mita

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=20140928154525.76cc5464@as \
    --to=cebbert.lkml@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=ddutile@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@redhat.com \
    --cc=peter@hurleysoftware.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.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.