From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Robin Murphy <robin.murphy@arm.com>,
Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org, linux-mm@kvack.org,
Christoph Hellwig <hch@lst.de>
Cc: Will.Deacon@arm.com, lorenzo.pieralisi@arm.com,
hanjun.guo@linaro.org, joro@8bytes.org, vbabka@suse.cz,
akpm@linux-foundation.org, mhocko@suse.com,
Tomasz.Nowicki@cavium.com, Robert.Richter@cavium.com,
jnair@caviumnetworks.com, gklkml16@gmail.com
Subject: Re: [PATCH 3/4] iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and comamnd queues
Date: Fri, 29 Sep 2017 14:13:50 +0200 [thread overview]
Message-ID: <7e270ffc-963c-c1c7-410c-ff3c2e767984@samsung.com> (raw)
In-Reply-To: <db28d6ff-77e5-ed59-c1b8-57c917564a68@arm.com>
Hi Robin,
On 2017-09-21 13:58, Robin Murphy wrote:
> [+Christoph and Marek]
>
> On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
>> Introduce smmu_alloc_coherent and smmu_free_coherent functions to
>> allocate/free dma coherent memory from NUMA node associated with SMMU.
>> Replace all calls of dmam_alloc_coherent with smmu_alloc_coherent
>> for SMMU stream tables and command queues.
> This doesn't work - not only do you lose the 'managed' aspect and risk
> leaking various tables on probe failure or device removal, but more
> importantly, unless you add DMA syncs around all the CPU accesses to the
> tables, you lose the critical 'coherent' aspect, and that's a horribly
> invasive change that I really don't want to make.
>
> Christoph, Marek; how reasonable do you think it is to expect
> dma_alloc_coherent() to be inherently NUMA-aware on NUMA-capable
> systems? SWIOTLB looks fairly straightforward to fix up (for the simple
> allocation case; I'm not sure it's even worth it for bounce-buffering),
> but the likes of CMA might be a little trickier...
I'm not sure if there is any dma-coherent implementation that is NUMA aware.
Maybe author should provide some benchmarks, which show that those
structures
should be allocated in NUMA-aware way?
On the other hand it is not that hard to add required dma_sync_* calls
around
all the code which updated those tables.
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-09-29 12:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 8:59 [PATCH 0/4] numa, iommu/smmu: IOMMU/SMMU driver optimization for NUMA systems Ganapatrao Kulkarni
2017-09-21 8:59 ` [PATCH 1/4] mm: move function alloc_pages_exact_nid out of __meminit Ganapatrao Kulkarni
2017-09-26 13:35 ` Michal Hocko
2017-09-21 8:59 ` [PATCH 2/4] numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu translation tables Ganapatrao Kulkarni
2017-09-21 11:11 ` Robin Murphy
2017-09-22 15:33 ` Ganapatrao Kulkarni
2017-09-21 8:59 ` [PATCH 3/4] iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and comamnd queues Ganapatrao Kulkarni
2017-09-21 11:58 ` Robin Murphy
2017-09-21 14:26 ` Christoph Hellwig
2017-09-29 12:13 ` Marek Szyprowski [this message]
2017-10-04 13:53 ` Ganapatrao Kulkarni
2017-10-18 13:36 ` Robin Murphy
2017-11-06 9:04 ` Ganapatrao Kulkarni
2017-09-21 8:59 ` [PATCH 4/4] iommu/dma, numa: Use NUMA aware memory allocations in __iommu_dma_alloc_pages Ganapatrao Kulkarni
2017-09-21 11:41 ` Robin Murphy
2017-09-22 15:44 ` Ganapatrao Kulkarni
2017-10-18 13:28 ` [PATCH 0/4] numa, iommu/smmu: IOMMU/SMMU driver optimization for NUMA systems Will Deacon
2018-08-22 13:44 ` John Garry
2018-08-22 14:56 ` Robin Murphy
2018-08-22 16:07 ` John Garry
2018-08-22 17:57 ` Ganapatrao Kulkarni
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=7e270ffc-963c-c1c7-410c-ff3c2e767984@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=Robert.Richter@cavium.com \
--cc=Tomasz.Nowicki@cavium.com \
--cc=Will.Deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ganapatrao.kulkarni@cavium.com \
--cc=gklkml16@gmail.com \
--cc=hanjun.guo@linaro.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jnair@caviumnetworks.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mhocko@suse.com \
--cc=robin.murphy@arm.com \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox