All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: joro@8bytes.org, robin.murphy@arm.com,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	ganapatrao.kulkarni@cavium.com, hch@lst.de,
	m.szyprowski@samsung.com, linuxarm@huawei.com
Subject: Re: [PATCH v3] iommu/dma: Use NUMA aware memory allocations in __iommu_dma_alloc_pages()
Date: Wed, 21 Nov 2018 16:57:55 +0000	[thread overview]
Message-ID: <20181121165755.GE24883@arm.com> (raw)
In-Reply-To: <24be0d21-63b1-c88d-fdfd-42575f12634f@huawei.com>

On Wed, Nov 21, 2018 at 04:47:48PM +0000, John Garry wrote:
> On 21/11/2018 16:07, Will Deacon wrote:
> >On Wed, Nov 21, 2018 at 10:54:10PM +0800, John Garry wrote:
> >>From: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> >>
> >>Change function __iommu_dma_alloc_pages() to allocate pages for DMA from
> >>respective device NUMA node. The ternary operator which would be for
> >>alloc_pages_node() is tidied along with this.
> >>
> >>We also include a change to use kvzalloc() for kzalloc()/vzalloc()
> >>combination.
> >>
> >>Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> >>[JPG: Added kvzalloc(), drop pages ** being device local, tidied ternary operator]
> >>Signed-off-by: John Garry <john.garry@huawei.com>
> >
> >Weird, you're missing a diffstat here.
> >
> >Anyway, the patch looks fine to me, but it would be nice if you could
> >justify the change with some numbers. Do you actually see an improvement
> >from this change?
> >
> 
> Hi Will,
> 
> Ah, I missed adding my comments explaining the motivation. It would be
> better in the commit log. Anyway, here's the snippet:
> 
> " ... as mentioned in [3], dma_alloc_coherent() uses the locality
> information from the device - as in direct DMA - so this patch is just
> applying this same policy.
> 
> [3]
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1692998.html"

Yes, please add to this to the commit log.

> I did have some numbers to show improvement in some scenarios when I tested
> this a while back which I'll dig out.
> 
> However I would say that some scenarios will improve and the opposite for
> others with this change, considering different conditions in which DMA
> memory may be used.

Well, if you can show that it's useful in some cases and not catastrophic in
others, then I think shooting for parity with direct DMA is a reasonable
justification for the change.

Will

  reply	other threads:[~2018-11-21 16:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 14:54 [PATCH v3] iommu/dma: Use NUMA aware memory allocations in __iommu_dma_alloc_pages() John Garry
2018-11-21 14:54 ` John Garry
2018-11-21 16:07 ` Will Deacon
2018-11-21 16:47   ` John Garry
2018-11-21 16:47     ` John Garry
2018-11-21 16:57     ` Will Deacon [this message]
2018-11-23 16:40       ` John Garry
2018-11-23 16:40         ` John Garry

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=20181121165755.GE24883@arm.com \
    --to=will.deacon@arm.com \
    --cc=ganapatrao.kulkarni@cavium.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=john.garry@huawei.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=m.szyprowski@samsung.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.