From: Shivank Garg <shivankg@amd.com>
To: <kmanaouil.dev@gmail.com>
Cc: <Frank.li@nxp.com>, <Jonathan.Cameron@huawei.com>,
<Liam.Howlett@oracle.com>, <akpm@linux-foundation.org>,
<aneesh.kumar@kernel.org>, <apopple@nvidia.com>,
<bharata@amd.com>, <byungchul@sk.com>, <dave.hansen@intel.com>,
<dave@stgolabs.net>, <david@kernel.org>, <djbw@kernel.org>,
<gourry@gourry.net>, <hannes@cmpxchg.org>, <jhubbard@nvidia.com>,
<jic23@kernel.org>, <joshua.hahnjy@gmail.com>,
<kinseyho@google.com>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, <ljs@kernel.org>, <matthew.brost@intel.com>,
<mhocko@suse.com>, <nathan.lynch@amd.com>, <nifan.cxl@gmail.com>,
<peterx@redhat.com>, <rakie.kim@sk.com>, <riel@surriel.com>,
<rientjes@google.com>, <rkodsara@amd.com>, <rppt@kernel.org>,
<shakeel.butt@linux.dev>, <shivankg@amd.com>, <sj@kernel.org>,
<stalexan@redhat.com>, <surenb@google.com>, <tj@kernel.org>,
<vbabka@kernel.org>, <vkoul@kernel.org>, <weixugc@google.com>,
<willy@infradead.org>, <xuezhengchu@huawei.com>,
<yiannis@zptcorp.com>, <ying.huang@linux.alibaba.com>,
<ziy@nvidia.com>
Subject:
Date: Wed, 10 Jun 2026 12:26:54 +0000 [thread overview]
Message-ID: <20260610122652.129407-3-shivankg@amd.com> (raw)
In-Reply-To: <20260609161742.phipg7eid3yy4j7f@wrangler>
...
> I'm still testing, but the initial implementation I wrote with
> DMAEngine had too much overhead because of the sgtable allocations
> and the conversion between kernel scatterlists to device descriptors.
> So I entirely bypassed the DMAEngine API by directly passing the folios
> lists to the driver.
>
> I know it depends on the use case. If you just want to offload with no
> latency requirements, then DMAEngine is fine, but if the goal is to
> achieve high bandwidth with minimal latency, then it's a problem.
>
> Another example, if you have to do several independent copies of 256 or
> 512 4KiB pages in a short period of time, there will to much stress on
> sgtable allocations.
>
> Another problem for low latency is DMA mapping.
>
> Anyway, I need to collect more numbers. I will try to share my insights
> with idxd asap.
Thanks, looking forward to those insights and numbers.
An IDXD specific implementation is good for experimentation, but
for upstream path, I think this would be hard to maintain and add duplicate
logic. The cleanest approch is the DMA_MEMCPY_SG API. So, a single offload
driver can drive any engine that implements it. dmaengine_prep_dma_memcpy_sg()
submits a whole src/dst scatterlist as one transaction, which cuts the
per-descriptor setup overhead that dominates for 4KB pages.
I've added a patch for dmaengine_prep_dma_memcpy_sg(), Could you look into
wiring up device_prep_dma_memcpy_sg hook in the IDXD?
This will keep it generic and address the bandwidth/latency problem for
small transfers.
Best Regards,
Shivank
---
From d60e4dcd58552cbc6c7ecee37df9e216ab0c5a4f Mon Sep 17 00:00:00 2001
From: Shivank Garg <shivankg@amd.com>
Date: Sun, 17 May 2026 18:19:10 +0000
Subject: [PATCH] dmaengine: add DMA_MEMCPY_SG transaction type
Currently, a client that wants to copy N (src, dst, len) tuples call
dmaengine_prep_dma_memcpy() N times, allocating N independent
dma_async_tx_descriptor. The provider has to treat them as independent
transactions, even when the underlying hardware can program them as
one descriptor group with a single completion. This overheads
are dominant for page size like 4KB.
To reduce this overheads, add DMA_MEMCPY_SG and the matching
device_prep_dma_memcpy_sg() callback taking paired src and dst
scatterlists, plus the dmaengine_prep_dma_memcpy_sg() inline wrapper.
The provider walks both lists in lockstep and retires the whole batch
as one async tx.
This API was removed by commit 0cae04373b77 ("dmaengine: remove
DMA_MEMCPY_SG once again") for lack of in-tree users. The user
this time is the page-migration copy offload driver.
Suggested-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
.../driver-api/dmaengine/provider.rst | 7 ++++
drivers/dma/dmaengine.c | 1 +
include/linux/dmaengine.h | 36 +++++++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
index f4ed98f701c9..fc3cab78e61a 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -175,6 +175,13 @@ Currently, the types available are:
``glReadPixels()``, which might require a verbatim copy of a huge
framebuffer from local device memory onto host memory.
+- DMA_MEMCPY_SG
+
+ - The device is able to do memory to memory scatter-gather transfers.
+
+ - This takes pair of src and dst scatterlists and retires the whole batch
+ as one async tx.
+
- DMA_XOR
- The device is able to perform XOR operations on memory areas
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 405bd2fbb4a3..665e00a96c8f 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1197,6 +1197,7 @@ int dma_async_device_register(struct dma_device *device)
}
CHECK_CAP(dma_memcpy, DMA_MEMCPY);
+ CHECK_CAP(dma_memcpy_sg, DMA_MEMCPY_SG);
CHECK_CAP(dma_xor, DMA_XOR);
CHECK_CAP(dma_xor_val, DMA_XOR_VAL);
CHECK_CAP(dma_pq, DMA_PQ);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index b3d251c9734e..9378e7a7803a 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -50,6 +50,7 @@ enum dma_status {
*/
enum dma_transaction_type {
DMA_MEMCPY,
+ DMA_MEMCPY_SG,
DMA_XOR,
DMA_PQ,
DMA_XOR_VAL,
@@ -824,6 +825,7 @@ struct dma_filter {
* @device_router_config: optional callback for DMA router configuration
* @device_free_chan_resources: release DMA channel's resources
* @device_prep_dma_memcpy: prepares a memcpy operation
+ * @device_prep_dma_memcpy_sg: prepares a memcpy operation over a scatter list
* @device_prep_dma_xor: prepares a xor operation
* @device_prep_dma_xor_val: prepares a xor validation operation
* @device_prep_dma_pq: prepares a pq operation
@@ -903,6 +905,11 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
struct dma_chan *chan, dma_addr_t dst, dma_addr_t src,
size_t len, unsigned long flags);
+ struct dma_async_tx_descriptor *(*device_prep_dma_memcpy_sg)(
+ struct dma_chan *chan,
+ struct scatterlist *dst_sg, unsigned int dst_nents,
+ struct scatterlist *src_sg, unsigned int src_nents,
+ unsigned long flags);
struct dma_async_tx_descriptor *(*device_prep_dma_xor)(
struct dma_chan *chan, dma_addr_t dst, dma_addr_t *src,
unsigned int src_cnt, size_t len, unsigned long flags);
@@ -1091,6 +1098,35 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy(
len, flags);
}
+/**
+ * dmaengine_prep_dma_memcpy_sg - Prepare a scatter-gather memcpy
+ * @chan: The channel to prepare on
+ * @dst_sg: Destination scatterlist
+ * @dst_nents: Number of mapped entries in @dst_sg
+ * @src_sg: Source scatterlist
+ * @src_nents: Number of mapped entries in @src_sg
+ * @flags: Dmaengine flags (e.g. DMA_PREP_INTERRUPT, DMA_CTRL_ACK)
+ *
+ * Submit a batch of memcpy operations described by two scatterlists as
+ * a single async transaction. All segments retire as one tx with one
+ * completion.
+ *
+ * Returns NULL if the channel does not implement this operation.
+ */
+static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy_sg(
+ struct dma_chan *chan,
+ struct scatterlist *dst_sg, unsigned int dst_nents,
+ struct scatterlist *src_sg, unsigned int src_nents,
+ unsigned long flags)
+{
+ if (!chan || !chan->device ||
+ !chan->device->device_prep_dma_memcpy_sg)
+ return NULL;
+
+ return chan->device->device_prep_dma_memcpy_sg(chan,
+ dst_sg, dst_nents, src_sg, src_nents, flags);
+}
+
static inline bool dmaengine_is_metadata_mode_supported(struct dma_chan *chan,
enum dma_desc_metadata_mode mode)
{
--
2.43.0
next prev parent reply other threads:[~2026-06-10 12:28 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 15:50 [PATCH 0/7] Accelerate page migration with batch copying and hardware offload Shivank Garg
2026-04-28 15:50 ` [PATCH 1/7] mm/migrate: rename PAGE_ migration flags to FOLIO_ Shivank Garg
2026-04-30 9:07 ` Huang, Ying
[not found] ` <20260518175429.1b28e8c1@jic23-huawei>
2026-05-18 23:51 ` Zi Yan
2026-06-09 5:34 ` Dev Jain
2026-06-09 6:17 ` Garg, Shivank
2026-06-09 6:23 ` Dev Jain
2026-04-28 15:50 ` [PATCH 2/7] mm/migrate: use migrate_info field instead of private Shivank Garg
2026-05-07 9:43 ` Huang, Ying
2026-05-11 15:22 ` David Hildenbrand (Arm)
2026-04-28 15:50 ` [PATCH 3/7] mm/migrate: skip data copy for already-copied folios Shivank Garg
2026-05-11 15:35 ` David Hildenbrand (Arm)
2026-05-20 15:21 ` Garg, Shivank
2026-06-08 11:26 ` Garg, Shivank
2026-06-08 15:18 ` David Hildenbrand (Arm)
2026-06-08 15:41 ` Zi Yan
2026-06-08 15:43 ` David Hildenbrand (Arm)
2026-06-08 19:32 ` Garg, Shivank
2026-06-09 12:55 ` David Hildenbrand (Arm)
2026-06-08 15:09 ` David Hildenbrand (Arm)
2026-04-28 15:50 ` [PATCH 4/7] mm/migrate: add batch-copy path in migrate_pages_batch Shivank Garg
2026-05-11 15:40 ` David Hildenbrand (Arm)
2026-05-20 15:06 ` Garg, Shivank
2026-06-08 15:25 ` David Hildenbrand (Arm)
2026-06-08 15:36 ` Zi Yan
2026-06-08 20:40 ` Garg, Shivank
2026-06-08 21:17 ` Karim Manaouil
2026-05-21 13:20 ` Garg, Shivank
2026-04-28 15:50 ` [PATCH 5/7] mm/migrate: add copy offload registration infrastructure Shivank Garg
2026-05-11 15:46 ` David Hildenbrand (Arm)
2026-05-20 15:24 ` Garg, Shivank
2026-05-11 15:50 ` David Hildenbrand (Arm)
2026-05-20 15:22 ` Garg, Shivank
2026-05-25 2:16 ` David Rientjes
2026-05-25 2:19 ` David Rientjes
2026-06-11 9:55 ` Karim Manaouil
2026-06-11 18:44 ` Zi Yan
2026-04-28 15:50 ` [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm) Shivank Garg
2026-06-09 0:00 ` Karim Manaouil
2026-06-09 7:31 ` Garg, Shivank
2026-06-09 16:17 ` Karim Manaouil
2026-06-10 12:26 ` Shivank Garg [this message]
2026-06-19 16:07 ` Karim Manaouil
2026-06-19 16:32 ` Karim Manaouil
2026-06-22 10:03 ` Garg, Shivank
2026-04-28 15:50 ` [PATCH 7/7] mm/migrate: adjust NR_MAX_BATCHED_MIGRATION for testing Shivank Garg
2026-04-28 17:11 ` [PATCH 0/7] Accelerate page migration with batch copying and hardware offload Garg, Shivank
2026-04-28 19:33 ` David Hildenbrand (Arm)
2026-04-29 5:51 ` Garg, Shivank
2026-04-30 8:47 ` Huang, Ying
2026-05-08 11:04 ` Garg, Shivank
2026-05-08 11:28 ` Huang, Ying
2026-05-08 12:34 ` Garg, Shivank
2026-05-09 7:49 ` Huang, Ying
2026-05-10 15:03 ` Garg, Shivank
2026-05-12 2:15 ` Huang, Ying
2026-05-20 15:23 ` Garg, Shivank
2026-05-07 9:58 ` Huang, Ying
2026-05-11 15:19 ` David Hildenbrand (Arm)
2026-05-12 1:45 ` Huang, Ying
2026-05-11 15:53 ` David Hildenbrand (Arm)
2026-05-12 2:35 ` Huang, Ying
2026-05-12 6:34 ` David Hildenbrand (Arm)
2026-05-14 6:42 ` Huang, Ying
2026-05-20 15:35 ` Garg, Shivank
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=20260610122652.129407-3-shivankg@amd.com \
--to=shivankg@amd.com \
--cc=Frank.li@nxp.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=apopple@nvidia.com \
--cc=bharata@amd.com \
--cc=byungchul@sk.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jhubbard@nvidia.com \
--cc=jic23@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kinseyho@google.com \
--cc=kmanaouil.dev@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=nathan.lynch@amd.com \
--cc=nifan.cxl@gmail.com \
--cc=peterx@redhat.com \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rkodsara@amd.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=stalexan@redhat.com \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
--cc=vkoul@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=xuezhengchu@huawei.com \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox