From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] Generic IOMMU page table framework
Date: Tue, 2 Dec 2014 13:53:56 +0000 [thread overview]
Message-ID: <20141202135356.GF9917@arm.com> (raw)
In-Reply-To: <1669896.md3tuDH5WL@avalon>
On Tue, Dec 02, 2014 at 01:47:41PM +0000, Laurent Pinchart wrote:
> On Monday 01 December 2014 12:05:34 Will Deacon wrote:
> > On Sun, Nov 30, 2014 at 10:03:08PM +0000, Laurent Pinchart wrote:
> > > On Thursday 27 November 2014 11:51:14 Will Deacon wrote:
> > > > The LPAE code implements support for 4k/2M/1G, 16k/32M and 64k/512M
> > > > mappings, but I decided not to implement the contiguous bit in the
> > > > interest of trying to keep the code semi-readable. This could always be
> > > > added later, if needed.
> > >
> > > Do you have any idea how much the contiguous bit can improve performances
> > > in real use cases ?
> >
> > It depends on the TLB, really. Given that the contiguous sized map directly
> > onto block sizes using different granules, I didn't see that the complexity
> > was worth it.
> >
> > For example:
> >
> > 4k granule : 16 contiguous entries => {64k, 32M, 16G}
> > 16k granule : 128 contiguous lvl3 entries => 2M
> > 32 contiguous lvl2 entries => 1G
> > 64k granule : 32 contiguous entries => {2M, 16G}
> >
> > If we use block mappings, then we get:
> >
> > 4k granule : 2M @ lvl2, 1G @ lvl1
> > 16k granule : 32M @ lvl2
> > 64k granule : 512M @ lvl2
> >
> > so really, we only miss the ability to create 16G mappings.
>
> In the general case maybe, but as far as I know my IOMMU only supports 4kB
> granule. Without support for the contiguous bit I loose the ability to create
> 64kB mappings, which I believe (but haven't test yet) will have a noticeable
> impact.
It would be good if you could confirm that. I'd have thought that you'd end
up using 2MB mappings most of the time for DMA buffers.
> > I doubt that hardware even implements that size in the TLB (the contiguous
> > bit is only a hint).
> >
> > On top of that, the contiguous bit leads to additional expense on unmap,
> > since you have extra TLB invalidation splitting the thing into non-
> > contiguous pages before you can do anything.
>
> That will only be required when doing partial unmaps, which shouldn't be that
> frequent. When unmapping a 64kB block there's no need to split the mapping
> beforehand.
Sure. I'm not against having support for the contiguous bit, I just don't
plan to implement it myself :)
Will
next prev parent reply other threads:[~2014-12-02 13:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 11:51 [PATCH 0/4] Generic IOMMU page table framework Will Deacon
2014-11-27 11:51 ` [PATCH 1/4] iommu: introduce generic page table allocation framework Will Deacon
2014-11-30 22:00 ` Laurent Pinchart
2014-12-01 12:13 ` Will Deacon
2014-12-01 13:33 ` Laurent Pinchart
2014-12-01 13:53 ` Will Deacon
2014-12-14 23:46 ` Laurent Pinchart
2014-12-15 9:45 ` Will Deacon
2014-11-27 11:51 ` [PATCH 2/4] iommu: add ARM LPAE page table allocator Will Deacon
2014-11-30 23:29 ` Laurent Pinchart
2014-12-01 17:23 ` Will Deacon
2014-12-01 20:21 ` Laurent Pinchart
2014-12-02 9:41 ` Will Deacon
2014-12-02 11:47 ` Laurent Pinchart
2014-12-05 18:48 ` Will Deacon
2014-12-02 22:41 ` Mitchel Humpherys
2014-12-03 11:11 ` Will Deacon
2014-12-05 10:55 ` Varun Sethi
2014-12-05 18:48 ` Will Deacon
2014-12-14 17:45 ` Varun Sethi
2014-12-15 13:30 ` Will Deacon
2014-12-15 15:43 ` Will Deacon
2014-12-15 16:35 ` Varun Sethi
2014-12-15 17:25 ` Will Deacon
2014-12-15 16:43 ` Varun Sethi
2014-12-15 17:20 ` Will Deacon
2014-11-27 11:51 ` [PATCH 3/4] iommu: add self-consistency tests to ARM LPAE IO " Will Deacon
2014-11-27 11:51 ` [PATCH 4/4] iommu/arm-smmu: make use of generic LPAE allocator Will Deacon
2014-11-30 22:03 ` [PATCH 0/4] Generic IOMMU page table framework Laurent Pinchart
2014-12-01 12:05 ` Will Deacon
2014-12-02 13:47 ` Laurent Pinchart
2014-12-02 13:53 ` Will Deacon [this message]
2014-12-02 22:29 ` Laurent Pinchart
2014-12-14 23:49 ` Laurent Pinchart
2014-12-15 16:10 ` Will Deacon
2014-12-15 17:33 ` Laurent Pinchart
2014-12-15 17:39 ` Will Deacon
2014-12-15 17:46 ` Laurent Pinchart
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=20141202135356.GF9917@arm.com \
--to=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).