From: "Garg, Shivank" <shivankg@amd.com>
To: Karim Manaouil <kmanaouil.dev@gmail.com>
Cc: <akpm@linux-foundation.org>, <david@kernel.org>,
<kinseyho@google.com>, <weixugc@google.com>, <ljs@kernel.org>,
<Liam.Howlett@oracle.com>, <vbabka@kernel.org>,
<willy@infradead.org>, <rppt@kernel.org>, <surenb@google.com>,
<mhocko@suse.com>, <ziy@nvidia.com>, <matthew.brost@intel.com>,
<joshua.hahnjy@gmail.com>, <rakie.kim@sk.com>, <byungchul@sk.com>,
<gourry@gourry.net>, <ying.huang@linux.alibaba.com>,
<apopple@nvidia.com>, <dave@stgolabs.net>,
<Jonathan.Cameron@huawei.com>, <rkodsara@amd.com>,
<vkoul@kernel.org>, <bharata@amd.com>, <sj@kernel.org>,
<rientjes@google.com>, <xuezhengchu@huawei.com>,
<yiannis@zptcorp.com>, <dave.hansen@intel.com>,
<hannes@cmpxchg.org>, <jhubbard@nvidia.com>, <peterx@redhat.com>,
<riel@surriel.com>, <shakeel.butt@linux.dev>,
<stalexan@redhat.com>, <tj@kernel.org>, <nifan.cxl@gmail.com>,
<jic23@kernel.org>, <aneesh.kumar@kernel.org>,
<nathan.lynch@amd.com>, <Frank.li@nxp.com>, <djbw@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: Re: [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm)
Date: Mon, 22 Jun 2026 15:33:31 +0530 [thread overview]
Message-ID: <054690e9-9113-49a6-844b-79d85045a3db@amd.com> (raw)
In-Reply-To: <20260619160725.lfcxrbj5go67qy6u@wrangler>
On 6/19/2026 9:37 PM, Karim Manaouil wrote:
> [You don't often get email from kmanaouil.dev@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi again Shivank,
>
> I just got some time to resume testing this on Intel Sapphire Rapids and
> something caught my attention, below
>
> On Tue, Apr 28, 2026 at 03:50:49PM +0000, Shivank Garg wrote:
>> +static int submit_dma_transfers(struct dma_work *work)
>> +{
>> + struct scatterlist *sg_src, *sg_dst;
>> + struct dma_async_tx_descriptor *tx;
>> + unsigned long flags = DMA_CTRL_ACK;
>> + dma_cookie_t cookie;
>> + int i;
>> +
>> + atomic_set(&work->pending, 1);
>> +
>> + sg_src = work->src_sgt->sgl;
>> + sg_dst = work->dst_sgt->sgl;
>> + for_each_sgtable_dma_sg(work->src_sgt, sg_src, i) {
>> + if (i == work->src_sgt->nents - 1)
>> + flags |= DMA_PREP_INTERRUPT;
>> +
>> + tx = dmaengine_prep_dma_memcpy(work->chan,
>> + sg_dma_address(sg_dst),
>> + sg_dma_address(sg_src),
>> + sg_dma_len(sg_src), flags);
>> + if (!tx) {
>> + atomic_set(&work->pending, 0);
>> + return -EIO;
>> + }
>> +
>> + if (i == work->src_sgt->nents - 1) {
>> + tx->callback = dma_completion_callback;
>> + tx->callback_param = work;
>> + }
>> +
>
> Here, you are submitting the descriptors one after the other and only
> the last descriptor has a callback, which in theory sounds correct as
> you expect the DMA engine to complete the descriptors in the same order
> they were submitted. However, in reality that's not really gauranteed.
>
> Intel DSA in particular can complete descriptors out of order. That
> means, the last descriptor submitted may not necessarily be the last
> descriptors that completes. In that case, you will return in
> folios_copy_dma() before the copy truly completes for all the folios.
>
> For correctness, we have to add a callback to every descriptor and
> initialize work->pending to the number of descriptors submitted then
> every time a descriptor completes, you call atomic_dec(&work->pending)
> and only complete the completion the moment it reaches zero.
>
> Btw, waiting for an interrupt adds massive scheduling overhead. If we
> also add the logic above, it'll get even worse. In my measurements, this
> can easily add up to 6ms, by which CPU page copy have easily completed
> the entire copy, which again adds to the list of latency concerns I
> raised in my other reply.
Thanks Karim for catching this.
I was not aware that descriptor chaining was not applicable for DSA.
Going forward, implementing the device_prep_dma_memcpy_sg() fixes this
broken assumption. So client will issue single transaction and see single
completion for whole batch. The ordering/correctness will become provider's
responsibility.
Thanks,
Shivank
next prev parent reply other threads:[~2026-06-22 10:03 UTC|newest]
Thread overview: 67+ 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
2026-05-18 16:54 ` Jonathan Cameron
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-05-18 16:56 ` Jonathan Cameron
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
2026-06-19 16:07 ` [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm) Karim Manaouil
2026-06-19 16:32 ` Karim Manaouil
2026-06-22 10:03 ` Garg, Shivank [this message]
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=054690e9-9113-49a6-844b-79d85045a3db@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 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.