From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/9] Renesas ipmmu-vmsa: Miscellaneous cleanups and fixes
Date: Tue, 22 Apr 2014 13:44:50 +0200 [thread overview]
Message-ID: <7322154.6fhsyAGbuH@avalon> (raw)
In-Reply-To: <20140422113423.GB8389@arm.com>
Hi Will,
On Tuesday 22 April 2014 12:34:23 Will Deacon wrote:
> On Mon, Apr 21, 2014 at 03:13:00PM +0100, Laurent Pinchart wrote:
> > Hello,
>
> Hi Laurent,
>
> > This patch set cleans up and fixes small issues in the ipmmu-vmsa driver.
> > The patches are based on top of "[PATCH v3] iommu: Add driver for Renesas
> > VMSA-compatible IPMMU" that adds the ipmmu-vmsa driver.
> >
> > The most interesting part of this series is the rewrite of the page table
> > management code. The IOMMU core guarantees that the map and unmap
> > operations will always be called only with page sizes advertised by the
> > driver. We can use that assumption to remove loops of PGD and PMD
> > entries, simplifying the code.
>
> Hmm, interesting. We still have to handle the case where a mapping created
> with one page-size could be unmapped with another though (in particular,
> unmapping part of the range).
Correct. I've implemented that in patch 9/9. Note that the patch also frees
pages use for page directory entries when they're not needed anymore, instead
of just marking them as invalid. That's something you probably should do in
the arm-smmu driver as well.
> > Will, would it make sense to perform the same cleanup for the arm-smmu
> > driver, or is there a reason to keep loops over PGD and PMD entries ?
> > Removing them makes the implementation of 68kB and 2MB pages easier.
>
> Is this an assumption that's relied on by other IOMMU drivers? It certainly
> makes mapping of large ranges less efficient than it could be, so I'm more
> inclined to set all the bits > PAGE_SIZE in pgsize_bitmap if it's only used
> to determine the granularity at which map/unmap are called (which is
> unrelated to what the hardware can actually do).
I haven't checked all the other IOMMU drivers, but at least the OMAP IOMMU
driver relies on the same assumption. Splitting map/unmap operations in page
size chunks inside the IOMMU core might indeed have a negative performance
impact due to locking, but I'm not sure it would be noticeable.
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2014-04-22 11:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 14:13 [PATCH 0/9] Renesas ipmmu-vmsa: Miscellaneous cleanups and fixes Laurent Pinchart
2014-04-21 14:13 ` [PATCH 1/9] iommu/ipmmu-vmsa: Cleanup failures of ARM mapping creation or attachment Laurent Pinchart
2014-04-21 14:13 ` [PATCH 2/9] iommu/ipmmu-vmsa: Fix the supported page sizes Laurent Pinchart
2014-04-21 14:13 ` [PATCH 3/9] iommu/ipmmu-vmsa: Define driver-specific page directory sizes Laurent Pinchart
2014-04-21 19:05 ` Sergei Shtylyov
2014-04-21 20:52 ` Laurent Pinchart
2014-04-21 14:13 ` [PATCH 4/9] iommu/ipmmu-vmsa: Set the PTE contiguous hint bit when possible Laurent Pinchart
2014-04-21 14:13 ` [PATCH 5/9] iommu/ipmmu-vmsa: PMD is never folded, PUD always is Laurent Pinchart
2014-04-21 14:13 ` [PATCH 6/9] iommu/ipmmu-vmsa: Rewrite page table management Laurent Pinchart
2014-04-21 14:13 ` [PATCH 7/9] iommu/ipmmu-vmsa: Support 2MB mappings Laurent Pinchart
2014-04-21 14:13 ` [PATCH 8/9] iommu/ipmmu-vmsa: Remove stage 2 PTE bits definitions Laurent Pinchart
2014-04-21 14:13 ` [PATCH 9/9] iommu/ipmmu-vmsa: Support clearing mappings Laurent Pinchart
2014-04-22 11:34 ` [PATCH 0/9] Renesas ipmmu-vmsa: Miscellaneous cleanups and fixes Will Deacon
2014-04-22 11:44 ` Laurent Pinchart [this message]
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=7322154.6fhsyAGbuH@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.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