Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Ganapatrao Kulkarni (4):
mm: move function alloc_pages_exact_nid out of __meminit
numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
translation tables
iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
comamnd queues
iommu/dma, numa: Use NUMA aware memory allocations in
__iommu_dma_alloc_pages
drivers/iommu/arm-smmu-v3.c | 57 +++++++++++++++++++++++++++++++++++++-----
drivers/iommu/dma-iommu.c | 17 +++++++------
drivers/iommu/io-pgtable-arm.c | 4 ++-
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 3 ++-
5 files changed, 67 insertions(+), 16 deletions(-)
--
2.9.4
This function can be used on NUMA systems in place of alloc_pages_exact
Adding code to export and to remove __meminit section tagging.
Signed-off-by: Ganapatrao Kulkarni <redacted>
---
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
function __arm_lpae_alloc_pages is used to allcoated memory for smmu
translation tables. updating function to allocate memory/pages
from the proximity domain of SMMU device.
Signed-off-by: Ganapatrao Kulkarni <redacted>
---
drivers/iommu/io-pgtable-arm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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.
Signed-off-by: Ganapatrao Kulkarni <redacted>
---
drivers/iommu/arm-smmu-v3.c | 57 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 51 insertions(+), 6 deletions(-)
From: Robin Murphy <robin.murphy@arm.com> Date: 2017-09-21 11:11:28
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
function __arm_lpae_alloc_pages is used to allcoated memory for smmu
translation tables. updating function to allocate memory/pages
from the proximity domain of SMMU device.
AFAICS, data->pgd_size always works out to a power-of-two number of
pages, so I'm not sure why we've ever needed alloc_pages_exact() here. I
think we could simply use alloc_pages_node() and drop patch #1.
Robin.
kvzalloc{,_node}() didn't exist when this code was first written, but it
does now - since you're touching it you may as well get rid of the whole
if-else and array_size local.
Further nit: some of the indentation below is a bit messed up.
Robin.
quoted hunk
if (!pages)
return NULL;
@@ -462,8 +463,9 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, unsigned int order = __fls(order_mask); order_size = 1U << order;- page = alloc_pages((order_mask - order_size) ?- gfp | __GFP_NORETRY : gfp, order);+ page = alloc_pages_node(numa_node,+ (order_mask - order_size) ?+ gfp | __GFP_NORETRY : gfp, order); if (!page) continue; if (!order)
From: Robin Murphy <robin.murphy@arm.com> Date: 2017-09-21 11:58:10
[+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...
Robin.
From: Christoph Hellwig <hch@lst.de> Date: 2017-09-21 14:26:42
On Thu, Sep 21, 2017 at 12:58:04PM +0100, Robin Murphy wrote:
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 think allocating data node local to dev is a good default. I'm not
sure if we'd still need a version that takes an explicit node, though.
On the one hand devices like NVMe or RDMA nics have queues that are
assigned to specific cpus and thus have an inherent affinity to given
nodes. On the other hand we'd still need to access the PCIe device,
so for it to make sense we'd need to access the dma memory a lot more
from the host than from the device, and I'm not sure if we ever have
devices where that is the case (which would not be optimal to start
with).
On Thu, Sep 21, 2017 at 4:41 PM, Robin Murphy [off-list ref] wrote:
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
quoted
function __arm_lpae_alloc_pages is used to allcoated memory for smmu
translation tables. updating function to allocate memory/pages
from the proximity domain of SMMU device.
AFAICS, data->pgd_size always works out to a power-of-two number of
pages, so I'm not sure why we've ever needed alloc_pages_exact() here. I
think we could simply use alloc_pages_node() and drop patch #1.
thanks Robin, i think we can replace with alloc_pages_node.
i will change as suggested in next version.
kvzalloc{,_node}() didn't exist when this code was first written, but it
does now - since you're touching it you may as well get rid of the whole
if-else and array_size local.
thanks, i will update in next version.
Further nit: some of the indentation below is a bit messed up.
ok, will fix it.
Robin.
quoted
if (!pages)
return NULL;
@@ -462,8 +463,9 @@ static struct page **__iommu_dma_alloc_pages(unsigned int count, unsigned int order = __fls(order_mask); order_size = 1U << order;- page = alloc_pages((order_mask - order_size) ?- gfp | __GFP_NORETRY : gfp, order);+ page = alloc_pages_node(numa_node,+ (order_mask - order_size) ?+ gfp | __GFP_NORETRY : gfp, order); if (!page) continue; if (!order)
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2017-09-29 12:13:58
Hi Robin,
On 2017-09-21 13:58, Robin Murphy wrote:
[+Christoph and Marek]
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
quoted
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
Hi Robin,
On Thu, Sep 21, 2017 at 5:28 PM, Robin Murphy [off-list ref] wrote:
[+Christoph and Marek]
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
quoted
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.
this implementation is similar to function used to allocate memory for
translation tables.
why do you see it affects to stream tables and not to page tables.
at runtime, both tables are accessed by SMMU only.
As said in cover letter, having stream table from respective NUMA node
is yielding
around 30% performance!
please suggest, if there is any better way to address this issue?
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...
Robin.
From: Will Deacon <hidden> Date: 2017-10-18 13:28:53
Hi Ganapat,
On Thu, Sep 21, 2017 at 02:29:18PM +0530, Ganapatrao Kulkarni wrote:
Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Are you planning to repost this series? The idea looks good, but it needs
some rework before it can be merged.
Thanks,
Will
From: Robin Murphy <robin.murphy@arm.com> Date: 2017-10-18 13:36:15
On 04/10/17 14:53, Ganapatrao Kulkarni wrote:
Hi Robin,
On Thu, Sep 21, 2017 at 5:28 PM, Robin Murphy [off-list ref] wrote:
quoted
[+Christoph and Marek]
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
quoted
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.
this implementation is similar to function used to allocate memory for
translation tables.
The concept is similar, yes, and would work if implemented *correctly*
with the aforementioned comprehensive and hugely invasive changes. The
implementation as presented in this patch, however, is incomplete and
badly broken.
By way of comparison, the io-pgtable implementations contain all the
necessary dma_sync_* calls, never relied on devres, and only have one
DMA direction to worry about (hint: the queues don't all work
identically). There are also a couple of practical reasons for using
streaming mappings with the DMA == phys restriction there - tracking
both the CPU and DMA addresses for each table would significantly
increase the memory overhead, and using the cacheable linear map address
in all cases sidesteps any potential problems with the atomic PTE
updates. Neither of those concerns apply to the SMMUv3 data structures,
which are textbook coherent DMA allocations (being tied to the lifetime
of the device, rather than transient).
why do you see it affects to stream tables and not to page tables.
at runtime, both tables are accessed by SMMU only.
As said in cover letter, having stream table from respective NUMA node
is yielding
around 30% performance!
please suggest, if there is any better way to address this issue?
I fully agree that NUMA-aware allocations are a worthwhile thing that we
want. I just don't like the idea of going around individual drivers
replacing coherent API usage with bodged-up streaming mappings - I
really think it's worth making the effort to to tackle it once, in the
proper place, in a way that benefits all users together.
Robin.
quoted
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...
Robin.
On Wed, Oct 18, 2017 at 7:06 PM, Robin Murphy [off-list ref] wrote:
On 04/10/17 14:53, Ganapatrao Kulkarni wrote:
quoted
Hi Robin,
On Thu, Sep 21, 2017 at 5:28 PM, Robin Murphy [off-list ref] wrote:
quoted
[+Christoph and Marek]
On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
quoted
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.
this implementation is similar to function used to allocate memory for
translation tables.
The concept is similar, yes, and would work if implemented *correctly*
with the aforementioned comprehensive and hugely invasive changes. The
implementation as presented in this patch, however, is incomplete and
badly broken.
By way of comparison, the io-pgtable implementations contain all the
necessary dma_sync_* calls, never relied on devres, and only have one
DMA direction to worry about (hint: the queues don't all work
identically). There are also a couple of practical reasons for using
streaming mappings with the DMA == phys restriction there - tracking
both the CPU and DMA addresses for each table would significantly
increase the memory overhead, and using the cacheable linear map address
in all cases sidesteps any potential problems with the atomic PTE
updates. Neither of those concerns apply to the SMMUv3 data structures,
which are textbook coherent DMA allocations (being tied to the lifetime
of the device, rather than transient).
quoted
why do you see it affects to stream tables and not to page tables.
at runtime, both tables are accessed by SMMU only.
As said in cover letter, having stream table from respective NUMA node
is yielding
around 30% performance!
please suggest, if there is any better way to address this issue?
I fully agree that NUMA-aware allocations are a worthwhile thing that we
want. I just don't like the idea of going around individual drivers
replacing coherent API usage with bodged-up streaming mappings - I
really think it's worth making the effort to to tackle it once, in the
proper place, in a way that benefits all users together.
Robin.
quoted
quoted
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...
IIUC, having DMA allocation per node may become issue for 32 bit PCI
devices connected on NODE 1 on IOMMU less platforms.
most of the platforms may have NODE 1 RAM located beyond 4GB and
having DMA allocation beyond 32bit for NODE1(and above) devices may
make 32 bit pci devices not usable.
DMA/IOMMU experts, please advise?
From: John Garry <hidden> Date: 2018-08-22 13:44:59
On 21/09/2017 09:59, Ganapatrao Kulkarni wrote:
Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Ganapatrao Kulkarni (4):
mm: move function alloc_pages_exact_nid out of __meminit
numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
translation tables
iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
comamnd queues
iommu/dma, numa: Use NUMA aware memory allocations in
__iommu_dma_alloc_pages
drivers/iommu/arm-smmu-v3.c | 57 +++++++++++++++++++++++++++++++++++++-----
drivers/iommu/dma-iommu.c | 17 +++++++------
drivers/iommu/io-pgtable-arm.c | 4 ++-
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 3 ++-
5 files changed, 67 insertions(+), 16 deletions(-)
Hi Ganapatrao,
Have you any plans for further work on this patchset? I have not seen
anything since this v1 was posted+discussed.
Thanks,
John
From: Robin Murphy <robin.murphy@arm.com> Date: 2018-08-22 14:56:54
Hi John,
On 22/08/18 14:44, John Garry wrote:
On 21/09/2017 09:59, Ganapatrao Kulkarni wrote:
quoted
Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command
queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Ganapatrao Kulkarni (4):
? mm: move function alloc_pages_exact_nid out of __meminit
? numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
??? translation tables
? iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
??? comamnd queues
? iommu/dma, numa: Use NUMA aware memory allocations in
??? __iommu_dma_alloc_pages
?drivers/iommu/arm-smmu-v3.c??? | 57
+++++++++++++++++++++++++++++++++++++-----
?drivers/iommu/dma-iommu.c????? | 17 +++++++------
?drivers/iommu/io-pgtable-arm.c |? 4 ++-
?include/linux/gfp.h??????????? |? 2 +-
?mm/page_alloc.c??????????????? |? 3 ++-
?5 files changed, 67 insertions(+), 16 deletions(-)
Hi Ganapatrao,
Have you any plans for further work on this patchset? I have not seen
anything since this v1 was posted+discussed.
Looks like I ended up doing the version of the io-pgtable change that I
suggested here, which was merged recently (4b123757eeaa). Patch #3
should also be effectively obsolete now since the SWIOTLB/dma-direct
rework (21f237e4d085). Apparently I also started reworking patch #4 in
my tree at some point but sidelined it - I think that was at least
partly due to another thread[1] which made it seem less clear-cut
whether this is always the right thing to do.
Robin.
[1]
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1693026.html
From: John Garry <hidden> Date: 2018-08-22 16:08:40
On 22/08/2018 15:56, Robin Murphy wrote:
Hi John,
On 22/08/18 14:44, John Garry wrote:
quoted
On 21/09/2017 09:59, Ganapatrao Kulkarni wrote:
quoted
Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command
queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Ganapatrao Kulkarni (4):
mm: move function alloc_pages_exact_nid out of __meminit
numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
translation tables
iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
comamnd queues
iommu/dma, numa: Use NUMA aware memory allocations in
__iommu_dma_alloc_pages
drivers/iommu/arm-smmu-v3.c | 57
+++++++++++++++++++++++++++++++++++++-----
drivers/iommu/dma-iommu.c | 17 +++++++------
drivers/iommu/io-pgtable-arm.c | 4 ++-
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 3 ++-
5 files changed, 67 insertions(+), 16 deletions(-)
Hi Ganapatrao,
Have you any plans for further work on this patchset? I have not seen
anything since this v1 was posted+discussed.
Hi Robin,
Thanks for the info. I thought I remembered 4b12 but couldn't put my
finger on it.
Looks like I ended up doing the version of the io-pgtable change that I
suggested here, which was merged recently (4b123757eeaa). Patch #3
should also be effectively obsolete now since the SWIOTLB/dma-direct
rework (21f237e4d085). Apparently I also started reworking patch #4 in
my tree at some point but sidelined it - I think that was at least
partly due to another thread[1] which made it seem less clear-cut
whether this is always the right thing to do.
Right, so #4 seems less straightforward and not directly related to
IOMMU driver anyway.
Cheers,
John
On Wed, Aug 22, 2018 at 9:08 AM John Garry [off-list ref] wrote:
On 22/08/2018 15:56, Robin Murphy wrote:
quoted
Hi John,
On 22/08/18 14:44, John Garry wrote:
quoted
On 21/09/2017 09:59, Ganapatrao Kulkarni wrote:
quoted
Adding numa aware memory allocations used for iommu dma allocation and
memory allocated for SMMU stream tables, page walk tables and command
queues.
With this patch, iperf testing on ThunderX2, with 40G NIC card on
NODE 1 PCI shown same performance(around 30% improvement) as NODE 0.
Ganapatrao Kulkarni (4):
mm: move function alloc_pages_exact_nid out of __meminit
numa, iommu/io-pgtable-arm: Use NUMA aware memory allocation for smmu
translation tables
iommu/arm-smmu-v3: Use NUMA memory allocations for stream tables and
comamnd queues
iommu/dma, numa: Use NUMA aware memory allocations in
__iommu_dma_alloc_pages
drivers/iommu/arm-smmu-v3.c | 57
+++++++++++++++++++++++++++++++++++++-----
drivers/iommu/dma-iommu.c | 17 +++++++------
drivers/iommu/io-pgtable-arm.c | 4 ++-
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 3 ++-
5 files changed, 67 insertions(+), 16 deletions(-)
Hi Ganapatrao,
Have you any plans for further work on this patchset? I have not seen
anything since this v1 was posted+discussed.
Hi Robin,
Thanks for the info. I thought I remembered 4b12 but couldn't put my
finger on it.
quoted
Looks like I ended up doing the version of the io-pgtable change that I
suggested here, which was merged recently (4b123757eeaa). Patch #3
should also be effectively obsolete now since the SWIOTLB/dma-direct
rework (21f237e4d085). Apparently I also started reworking patch #4 in
my tree at some point but sidelined it - I think that was at least
partly due to another thread[1] which made it seem less clear-cut
whether this is always the right thing to do.
Right, so #4 seems less straightforward and not directly related to
IOMMU driver anyway.
thanks Robin for pulling up the patch. I couldn't followup with this
due to other tasks.