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


  parent reply	other threads:[~2026-06-22 10:04 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox