From: Stepan Moskovchenko <stepanm@codeaurora.org>
To: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Kai Huang <mail.kai.huang@gmail.com>,
Ohad Ben-Cohen <ohad@wizery.com>,
iommu@lists.linux-foundation.org, linux-omap@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-arm-kernel@lists.infradead.org,
David Brown <davidb@codeaurora.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, Hiroshi Doyu <hdoyu@nvidia.com>,
KyongHo Cho <pullip.cho@samsung.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
Date: Thu, 10 Nov 2011 13:12:00 -0800 [thread overview]
Message-ID: <4EBC3E20.20301@codeaurora.org> (raw)
In-Reply-To: <20111110170918.GE13213@amd.com>
On 11/10/2011 9:09 AM, Joerg Roedel wrote:
> The plan is to have a single DMA-API implementation for all IOMMU
> drivers (X86 and ARM) which just uses the IOMMU-API. But to make this
> performing reasonalbly well a few changes to the IOMMU-API are
> required. I already have some ideas which we can discuss if you want.
I have been experimenting with an iommu_map_range call, which maps a
given scatterlist of discontiguous physical pages into a contiguous
virtual region at a given IOVA. This has some performance advantages
over just calling iommu_map iteratively. First, it reduces the amount of
table walking / calculation needed for mapping each page, given how you
know that all the pages will be mapped into a single
virtually-contiguous region (so in most cases, the first-level table
calculation can be reused). Second, it allows one to defer the TLB (and
sometimes cache) maintenance operations until the entire scatterlist has
been mapped, rather than doing a TLB invalidate after mapping each page,
as would have been the case if iommu_map were just being called from
within a loop. Granted, just using iommu_map many times may be
acceptable on the slow path, but I have seen significant performance
gains when using this approach on the fast path.
Steve
WARNING: multiple messages have this Message-ID (diff)
From: stepanm@codeaurora.org (Stepan Moskovchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware
Date: Thu, 10 Nov 2011 13:12:00 -0800 [thread overview]
Message-ID: <4EBC3E20.20301@codeaurora.org> (raw)
In-Reply-To: <20111110170918.GE13213@amd.com>
On 11/10/2011 9:09 AM, Joerg Roedel wrote:
> The plan is to have a single DMA-API implementation for all IOMMU
> drivers (X86 and ARM) which just uses the IOMMU-API. But to make this
> performing reasonalbly well a few changes to the IOMMU-API are
> required. I already have some ideas which we can discuss if you want.
I have been experimenting with an iommu_map_range call, which maps a
given scatterlist of discontiguous physical pages into a contiguous
virtual region at a given IOVA. This has some performance advantages
over just calling iommu_map iteratively. First, it reduces the amount of
table walking / calculation needed for mapping each page, given how you
know that all the pages will be mapped into a single
virtually-contiguous region (so in most cases, the first-level table
calculation can be reused). Second, it allows one to defer the TLB (and
sometimes cache) maintenance operations until the entire scatterlist has
been mapped, rather than doing a TLB invalidate after mapping each page,
as would have been the case if iommu_map were just being called from
within a loop. Granted, just using iommu_map many times may be
acceptable on the slow path, but I have seen significant performance
gains when using this approach on the fast path.
Steve
next prev parent reply other threads:[~2011-11-10 21:12 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 11:27 [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 1/7] iommu/core: stop converting bytes to page order back and forth Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-11-10 6:17 ` Kai Huang
2011-11-10 6:17 ` Kai Huang
2011-11-10 7:31 ` Ohad Ben-Cohen
2011-11-10 7:31 ` Ohad Ben-Cohen
2011-11-10 12:16 ` cody
2011-11-10 12:16 ` cody
2011-11-10 13:08 ` Joerg Roedel
2011-11-10 13:08 ` Joerg Roedel
2011-11-10 13:08 ` Joerg Roedel
2011-11-10 14:35 ` cody
2011-11-10 14:35 ` cody
2011-11-10 14:51 ` Joerg Roedel
2011-11-10 14:51 ` Joerg Roedel
2011-11-10 14:51 ` Joerg Roedel
2011-11-10 15:28 ` David Woodhouse
2011-11-10 15:28 ` David Woodhouse
2011-11-10 17:09 ` Joerg Roedel
2011-11-10 17:09 ` Joerg Roedel
2011-11-10 17:09 ` Joerg Roedel
2011-11-10 19:28 ` David Woodhouse
2011-11-10 19:28 ` David Woodhouse
2011-11-11 12:58 ` Joerg Roedel
2011-11-11 12:58 ` Joerg Roedel
2011-11-11 12:58 ` Joerg Roedel
2011-11-11 13:27 ` David Woodhouse
2011-11-11 13:27 ` David Woodhouse
2011-11-11 14:18 ` Joerg Roedel
2011-11-11 14:18 ` Joerg Roedel
2011-11-11 14:18 ` Joerg Roedel
2011-11-11 13:17 ` Changing IOMMU-API for generic DMA-mapping " Joerg Roedel
2011-11-11 13:17 ` Joerg Roedel
2011-11-24 12:52 ` Marek Szyprowski
2011-11-24 12:52 ` Marek Szyprowski
2011-11-24 15:27 ` 'Joerg Roedel'
2011-11-24 15:27 ` 'Joerg Roedel'
2011-11-24 15:27 ` 'Joerg Roedel'
2011-11-10 21:12 ` Stepan Moskovchenko [this message]
2011-11-10 21:12 ` [PATCH v4 2/7] iommu/core: split mapping to page sizes as " Stepan Moskovchenko
2011-11-11 13:24 ` Joerg Roedel
2011-11-11 13:24 ` Joerg Roedel
2011-11-11 13:24 ` Joerg Roedel
2011-11-12 2:04 ` Stepan Moskovchenko
2011-11-12 2:04 ` Stepan Moskovchenko
2011-11-13 1:43 ` KyongHo Cho
2011-11-13 1:43 ` KyongHo Cho
2011-10-17 11:27 ` [PATCH v4 3/7] iommu/omap: announce supported page sizes Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 4/7] iommu/msm: " Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 5/7] iommu/amd: " Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 6/7] iommu/intel: " Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` [PATCH v4 7/7] iommu/core: remove the temporary pgsize settings Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-10-17 11:27 ` Ohad Ben-Cohen
2011-11-08 12:57 ` [PATCH v4 0/7] iommu: split mapping to page sizes as supported by the hardware Ohad Ben-Cohen
2011-11-08 12:57 ` Ohad Ben-Cohen
2011-11-08 14:01 ` Joerg Roedel
2011-11-08 14:01 ` Joerg Roedel
2011-11-08 14:01 ` Joerg Roedel
2011-11-08 14:03 ` Ohad Ben-Cohen
2011-11-08 14:03 ` Ohad Ben-Cohen
2011-11-08 16:23 ` Joerg Roedel
2011-11-08 16:23 ` Joerg Roedel
2011-11-08 16:23 ` Joerg Roedel
2011-11-08 16:43 ` Ohad Ben-Cohen
2011-11-08 16:43 ` Ohad Ben-Cohen
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=4EBC3E20.20301@codeaurora.org \
--to=stepanm@codeaurora.org \
--cc=Joerg.Roedel@amd.com \
--cc=arnd@arndb.de \
--cc=davidb@codeaurora.org \
--cc=dwmw2@infradead.org \
--cc=hdoyu@nvidia.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mail.kai.huang@gmail.com \
--cc=ohad@wizery.com \
--cc=pullip.cho@samsung.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.