From: "Garg, Shivank" <shivankg@amd.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, bharata@amd.com,
raghavendra.kodsarathimmappa@amd.com, Michael.Day@amd.com,
dmaengine@vger.kernel.org, vkoul@kernel.org
Subject: Re: [RFC PATCH 0/5] Enhancements to Page Migration with Batch Offloading via DMA
Date: Mon, 17 Jun 2024 17:10:18 +0530 [thread overview]
Message-ID: <c024d035-dc94-4e89-a935-795ab2ce24e7@amd.com> (raw)
In-Reply-To: <Zm0SWZKcRrngCUUW@casper.infradead.org>
Hi Matthew,
On 6/15/2024 9:32 AM, Matthew Wilcox wrote:
> On Sat, Jun 15, 2024 at 03:45:20AM +0530, Shivank Garg wrote:
>
> You haven't measured the important thing though -- what's the cost
> _to userspace_? When the CPU does the copy, the data is now
> cache-hot in that CPU's cache. When the DMA engine does the copy,
> it's not cache-hot in any CPU.
>
> Now, this may not be a big problem. I don't think we do anything to
> ensure that the CPU that is going to access the folio in userspace
> is the one which does the copy.
>
> But your methodology is wrong.
You're right about importance of measuring the cost to userspace.
I initially focused on analyzing the folio_copy overheads within migrate_pages to identify potential optimizations opportunities using DMA hardware accelerators.
To address this, I'm planning extend my experiments to measure the cost to userspace specifically related to cache-hotness. This will involve the accessing the migrated pages after the migration process is complete, and measuring the resulting latency to read/write.
This approach of DMA-offloading could possibly help in scenarios involving bulk data copying with workload size >> cache capacity or incurs a large shootdown overhead.
The userspace cost analysis will provide a more comprehensive picture of page-migration using CPU v/s DMA-offloading.
I appreciate your feedback.
Shivank
next prev parent reply other threads:[~2024-06-17 11:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 22:15 [RFC PATCH 0/5] Enhancements to Page Migration with Batch Offloading via DMA Shivank Garg
2024-06-14 22:15 ` [RFC PATCH 1/5] mm: separate move/undo doing on folio list from migrate_pages_batch() Shivank Garg
2024-06-14 22:15 ` [RFC PATCH 2/5] mm: add folios_copy() for copying pages in batch during migration Shivank Garg
2024-06-14 22:15 ` [RFC PATCH 3/5] mm: add migrate_folios_batch_move to batch the folio move operations Shivank Garg
2024-06-14 22:15 ` [RFC PATCH 4/5] mm: add support for DMA folio Migration Shivank Garg
2024-06-14 22:15 ` [RFC PATCH 5/5] dcbm: add dma core batch migrator for batch page offloading Shivank Garg
2024-06-15 4:02 ` [RFC PATCH 0/5] Enhancements to Page Migration with Batch Offloading via DMA Matthew Wilcox
2024-06-17 11:40 ` Garg, Shivank [this message]
2024-06-25 8:57 ` 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=c024d035-dc94-4e89-a935-795ab2ce24e7@amd.com \
--to=shivankg@amd.com \
--cc=Michael.Day@amd.com \
--cc=akpm@linux-foundation.org \
--cc=bharata@amd.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=raghavendra.kodsarathimmappa@amd.com \
--cc=vkoul@kernel.org \
--cc=willy@infradead.org \
/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