All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Juergen Gross <jgross@suse.com>,
	Tangquan Zheng <zhengtangquan@oppo.com>,
	Barry Song <baohua@kernel.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Leon Romanovsky <leon@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	will@kernel.org, Joerg Roedel <joro@8bytes.org>,
	Barry Song <21cnbao@gmail.com>,
	linux-kernel@vger.kernel.org,
	Suren Baghdasaryan <surenb@google.com>,
	iommu@lists.linux.dev, Xueyuan Chen <xueyuan.chen21@gmail.com>,
	Marc Zyngier <maz@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	robin.murphy@arm.com, Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Huacai Zhou <zhouhuacai@oppo.com>
Subject: Re: [PATCH v3 0/5] dma-mapping: arm64: support batched cache sync
Date: Fri, 13 Mar 2026 19:36:50 +0000	[thread overview]
Message-ID: <abRnUk-vfvS51FtW@arm.com> (raw)
In-Reply-To: <3ece80c7-697e-4d46-a6f8-49c07b0117a1@samsung.com>

On Tue, Mar 03, 2026 at 05:33:37PM +0100, Marek Szyprowski wrote:
> On 28.02.2026 23:11, Barry Song wrote:
> > From: Barry Song <baohua@kernel.org>
> >
> > Many embedded ARM64 SoCs still lack hardware cache coherency support, which
> > causes DMA mapping operations to appear as hotspots in on-CPU flame graphs.
> >
> > For an SG list with *nents* entries, the current dma_map/unmap_sg() and DMA
> > sync APIs perform cache maintenance one entry at a time. After each entry,
> > the implementation synchronously waits for the corresponding region’s
> > D-cache operations to complete. On architectures like arm64, efficiency can
> > be improved by issuing all entries’ operations first and then performing a
> > single batched wait for completion.
> >
> > Tangquan's results show that batched synchronization can reduce
> > dma_map_sg() time by 64.61% and dma_unmap_sg() time by 66.60% on an MTK
> > phone platform (MediaTek Dimensity 9500). The tests were performed by
> > pinning the task to CPU7 and fixing the CPU frequency at 2.6 GHz,
> > running dma_map_sg() and dma_unmap_sg() on 10 MB buffers (10 MB / 4 KB
> > sg entries per buffer) for 200 iterations and then averaging the
> > results.
> >
> > Thanks to Xueyuan for volunteering to take on the testing tasks. He
> > put significant effort into validating paths such as IOVA link/unlink
> > and SWIOTLB on RK3588 boards with NVMe.
> 
> Catalin, Will, I would like to merge this to dma-mapping tree, give Your 
> ack or comment if You are okay with ARM64 related parts.

Sorry for the delay. Yes, feel free to pick them up. I doubt there would
be any conflicts in this area with what I'm merging through the arm64
tree.

Thanks.

-- 
Catalin


WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Barry Song <21cnbao@gmail.com>,
	robin.murphy@arm.com, will@kernel.org, iommu@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Barry Song <baohua@kernel.org>,
	Leon Romanovsky <leon@kernel.org>,
	Ada Couprie Diaz <ada.coupriediaz@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Joerg Roedel <joro@8bytes.org>, Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Tangquan Zheng <zhengtangquan@oppo.com>,
	Huacai Zhou <zhouhuacai@oppo.com>,
	Xueyuan Chen <xueyuan.chen21@gmail.com>
Subject: Re: [PATCH v3 0/5] dma-mapping: arm64: support batched cache sync
Date: Fri, 13 Mar 2026 19:36:50 +0000	[thread overview]
Message-ID: <abRnUk-vfvS51FtW@arm.com> (raw)
In-Reply-To: <3ece80c7-697e-4d46-a6f8-49c07b0117a1@samsung.com>

On Tue, Mar 03, 2026 at 05:33:37PM +0100, Marek Szyprowski wrote:
> On 28.02.2026 23:11, Barry Song wrote:
> > From: Barry Song <baohua@kernel.org>
> >
> > Many embedded ARM64 SoCs still lack hardware cache coherency support, which
> > causes DMA mapping operations to appear as hotspots in on-CPU flame graphs.
> >
> > For an SG list with *nents* entries, the current dma_map/unmap_sg() and DMA
> > sync APIs perform cache maintenance one entry at a time. After each entry,
> > the implementation synchronously waits for the corresponding region’s
> > D-cache operations to complete. On architectures like arm64, efficiency can
> > be improved by issuing all entries’ operations first and then performing a
> > single batched wait for completion.
> >
> > Tangquan's results show that batched synchronization can reduce
> > dma_map_sg() time by 64.61% and dma_unmap_sg() time by 66.60% on an MTK
> > phone platform (MediaTek Dimensity 9500). The tests were performed by
> > pinning the task to CPU7 and fixing the CPU frequency at 2.6 GHz,
> > running dma_map_sg() and dma_unmap_sg() on 10 MB buffers (10 MB / 4 KB
> > sg entries per buffer) for 200 iterations and then averaging the
> > results.
> >
> > Thanks to Xueyuan for volunteering to take on the testing tasks. He
> > put significant effort into validating paths such as IOVA link/unlink
> > and SWIOTLB on RK3588 boards with NVMe.
> 
> Catalin, Will, I would like to merge this to dma-mapping tree, give Your 
> ack or comment if You are okay with ARM64 related parts.

Sorry for the delay. Yes, feel free to pick them up. I doubt there would
be any conflicts in this area with what I'm merging through the arm64
tree.

Thanks.

-- 
Catalin

  reply	other threads:[~2026-03-13 19:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260228221143eucas1p12a276d4216b6ce0f3c374b093f73acd5@eucas1p1.samsung.com>
2026-02-28 22:11 ` [PATCH v3 0/5] dma-mapping: arm64: support batched cache sync Barry Song
2026-02-28 22:11   ` Barry Song
2026-02-28 22:12   ` [PATCH v3 1/5] arm64: Provide dcache_by_myline_op_nosync helper Barry Song
2026-02-28 22:12     ` Barry Song
2026-03-13 19:35     ` Catalin Marinas
2026-03-13 19:35       ` Catalin Marinas
2026-02-28 22:12   ` [PATCH v3 2/5] arm64: Provide dcache_clean_poc_nosync helper Barry Song
2026-02-28 22:12     ` Barry Song
2026-03-13 19:35     ` Catalin Marinas
2026-03-13 19:35       ` Catalin Marinas
2026-02-28 22:12   ` [PATCH v3 3/5] arm64: Provide dcache_inval_poc_nosync helper Barry Song
2026-02-28 22:12     ` Barry Song
2026-03-13 19:35     ` Catalin Marinas
2026-03-13 19:35       ` Catalin Marinas
2026-03-03 16:33   ` [PATCH v3 0/5] dma-mapping: arm64: support batched cache sync Marek Szyprowski
2026-03-03 16:33     ` Marek Szyprowski
2026-03-13 19:36     ` Catalin Marinas [this message]
2026-03-13 19:36       ` Catalin Marinas
2026-03-16  7:24       ` Marek Szyprowski
2026-03-16  7:24         ` Marek Szyprowski

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=abRnUk-vfvS51FtW@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=21cnbao@gmail.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=baohua@kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=leon@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maz@kernel.org \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=robin.murphy@arm.com \
    --cc=ryan.roberts@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=surenb@google.com \
    --cc=will@kernel.org \
    --cc=xueyuan.chen21@gmail.com \
    --cc=zhengtangquan@oppo.com \
    --cc=zhouhuacai@oppo.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.