Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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



  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